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PREFACE 


This manual is the third of three volumes dealing with the subject "Communications 
Processing Facility". 


The MCS User Guide deals with all programming aspects of communications in GPL and 
MCS COBOL, which includes not only the communications elements but also the use of 
run-time packages. It treats the system implementation of the line procedures and 
gives examples of how to program terminals. The manual deals with the utility 
QMAINT, which enables the user to perform maintenance on disk and memory queues 
defined for the network at CNC generation. 


In the three volumes of "Communications Processing Facility", the term "64/DPS 7" 
is synonymous with "DPS 7", the prefix "64" being a "carry-over" from previous re- 
leases. The keyword "HL64'"' designates the DPS 7 as a CPU-terminal in the URP local 
network and appears in the CNC declaration described in the Network Generation Ma- 
nual. 


The term "MAM'' (Message Necess Method) is used only in the context of MAM as a sy- 
Stem module of GCOS 7, such as MAM Error Messages in the Job Occurrence Report. 0O- 
therwise, the term "MCS" (Message Control System) which groups MAM with QMON, is 
used to qualify user-defined communications applications. 


For the current release, synchronous links for terminals of the VIP line procedure 
are directly supported via a URP packet link over the TRANSPAC secondary network. 
These synchronous links are provided by 

« DCU7010 convertor for VIP-type terminals : VIP7001 / 7700 / 7760, TTS7800 & TTU8221 
» TCU7022 / 7043 terminal concentrators for QUESTAR terminals : DKU7007 / 7107 / 7211. 


TRANSPAC refers specifically to the public data network in France, the use of 
which is contracted by PIT subscription. 


This manual is intended for the systems engineer and programmer/analyst for speci- 
fying and writing an MCS application for DPS 7 communications systems. The DPS 7 
communications system is set up and tailored by the use of the CNC utility, see 
the Network Generation Manual. 


Section I introduces the essential user-visible interface with the communications 
network. This section which leads on to the user-facilities provided by MCS, be- 
gins with a synopsis of "Communications Overview" which also serves as a reference 
to Distributed Systems Architecture as implemented by the DPS 7. 


Section II describes MCS in terms of a uSer-queue access method shared at system 
level allowing the exchange of messages to and from the terminals. It explains the 
Structure of the MCS load-module and the means of linking mono- and multi-process 
load-modules. It also gives the run-time JCL for the MCS application. 


Section III deals with MCS data processing, in particular, the symbolic represent- 
ation of data, and the various ways that MCS deals with data formats. It also 
gives details of representing data in the form of graphic efeeere that bake into 
account national language options. _ 
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Se eceion Iv. dascvibes the dyrianics of establishing ‘the: connection eaescea users, 
represented by terminals and applications, the connection interface between local 
and remote users being handled by MCS. It deals with the various Ey Pe? of connect) 
ions available over the DPS 7 network. | | : 7 7 


Section V deals with the line procedures supporting transmission protocols for 
terminals available to MCS. It describes these procedures implemented at system | 

level and, apart from-BSC2780, ‘are not uservisible. “In ‘the- case‘ of BSC2780, cer- 
tain reserved control codes must not be used by the application. ; 


Section VI gives examples of how to program terminals according to their funct- 
ional characteristics and line procedures. This information concerns the program- 
ming interface for both MCS as well as TDS. The difference in these two subsys- 
tems is that symbolic representation of data is not available for TDS. 


Section VII deals with QMAINT through which the user maintains the queues de- 
clared at network generation. These disk and memory queues can be systematically 
updated, that is, purged or redefined, at the end of the communications session. 
In addition, QMAINT allows the listing of queue status within the network. — 


Section VIII describes the events occurring during a communications session in 
terms of the parts played by the user and the system Dynamics of communications 
is a detailed account of the network environment in which the various software | 
components interact to enable message exchange and allocation of resources. 


Appendix A gives an example of an MCS application written in MCS COBOL and GPL, 
testing the TWA option, in which the operator must key in the required reply. 


Appendix B lists the QMAINT sysout report which enables the user to ensure that 
maintenance functions specified on the queues have been executed. 


Appendix C lists and explains MAM error messages in the Job Occurrence Report, _ 
QMAINT error messages in the sysout report and the JOR, and the "return-codes"'. 


Appendix D lists and explains the communications status keys, in terms of the 
conditions in which they occur for the five communications verbs. 


The other two volumes dealing with "Communications Processing Facility" are, 
« 47A2 01UC Communications Overview 
- 47A2 02UC Network Generation. 


The Communications Overview Manual describes how DPS 7 network processing imple- 
ments DSA techniques. It treats both primary and secondary networks and explains 
how both are supported by GCOS 7 communications components. A description is } also 
given on the TRANSPAC X. 25 link. 


The Network Generation Manual deals with the Communications Network Configurator 
(CNC) utility and is a reference document for the CNC commands used to generate 
the primary, secondary and TRANSPAC networks. Until the current release, the only 
primary network supported was the DPS 7 functioning as a "host" accessing its 
remote systems through the intermediary of its "front-end'' system, the DN7100. 
For the current release, the primary network configuration has been extended to 
the DPS 7 functioning as "Satellite" thereby directly accessing its remote sys- 
tems. 
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The following publications give further details to the topics mentioned in this 
manual, 
© For DPS 7 implementation of DSA concepts in a networking environment, 

¢ 47A2 01UC Communications Overview 


° For a reference to the CNC commands when generating the DPS 7 network, 
e 4742 02UC Network Generation 


° For coding MCS applications, 
o 47A2 35UL GPL Language Reference Manual 
e 47A2 36UL GPL User Guide 
© 47A2 37UL GPL System Primitives 
« 47A2 01UL COBOL 74 Language Reference Manual 
e 47A2 O02UL COBOL 74 User Guide 


° For information on linking compile units, 
. 47A2 O1UP LIBMAINT Reference Manual 
o 47A2 O2UP  LIBMAINT User Guide 
e 4742 10UP Linker User Guide 


° For file allocation when using disk queues, 
o 47A2 O5UF Data Management Utilities User Guide 


© For $QASSIGN and run-time JCL, 
© 47A2 1109 JCL Reference Manual 
e 4742 12UJ JCL User Guide 


© For GCOS 7 communications operator interface affecting transmission modes, 
© 47A2 O4UC Terminal Operations 
e 47A2 O5UC Network Control Terminal Operations 


° For GCOS 7 console operator interface for modifying scheduling, 
- 47A2 01UU System Operator's Guide | 


© For a description of catalog access rights, 
e 47A2 01US System Administrator's Manual 


° For general information on DPS 7 installations, 
» 30A1 8265 Functional Characteristics for DPS 7/x0 
» 93Ai1 8695 Functional Characteristics for DPS 7/x5 
© 47A2 O4UG System Overview | 


so o For a résumé of all aspects of “networking applicable : to he DPS 1 
_ 47A2. O9UC Telecommunications Reference Card | | 
° For formatting the DKU7007, DKU7107, DKU7211, VIP7700 (VIPT001. aud vIE7700), 
| ~VIP7760 and IBM3270 screens in a TDS environment, 
« 47A2 10UT . irl User Guide 


Suggestions and criticisms concerning the form, content and ‘purpose of this manu- 
al are invited. 


A Technical Publications Remarks Form is included at the end of the manual Fae 
this purpose. 


Each section of this document is structured according to the EReine hierarchy 
Shown below. 


Each pete indicates the relative never of the text which follows ite 


Level Heading Format 


1 (highest) ALL CAPITAL LETTERS, UNDERLINED 


2 : Initial Capital Letters Under lined | 

3 ALL GAPITALS, NOT UNDERLINED 

4 | Initial Capital Letters, Not Underlined 
5 (lowest) ALL CAPITAL LETTERS FOLLOWED BY COLON : 


text begins on the same line 
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SECTION I 


INTRODUCTION 


MCS applications, written in either MCS COBOL or GPL, require access through 
queues to the communications network. These queues are defined by the user. 


In this respect, such user-defined applications differ from the communications 
services, collectively termed VCAM subsystems. VGAM allows direct communication 
between these subsystems and terminals, and between the subsystems themselves. 
The user is not concerned with queues. 


The user interface to the communications network is described in terms of 
e networking environment 
« communications components 


e MCS 
« QMAINT. 


ACCESS TO MCS OVER FNPS/DN7100 


The DN7100 software release concurrent with Release V1 of GCOS7 is DNS B2 
(V2.6). Configurable connections over the DN7100 supported for the current re- 
lease are as follows. 

The DN7100 terminal manager supports both TWA and TWS session protocols, the 
latter allowing VIP KCT terminals, which include QUESTAR, to connect over the 
DN7i00 to access MCS in the DPS 7 host. 


Session control in both the DN7100 and the DPS 7 supports TWS protocol, there- ff 
by allowing the link-up of MCS applications Fests in the DPS 7 host (local) 


ane in its configured remote systems. 


_ For the secondary network, BINS allows all standard terminals of the differ- 
ent line procedures to’ access MCS in the DPS 7 For as long as the line pro- 
cedure is supported in the DPS 7, there are no connection restrictions. ~ 


For the primary network, the TNS function of BINS/HDLC allows the link-up of 
MCS applications residing in the DPS 7 satellite (local) and in its configured 
remote systems. ae | 


Networking Environment 
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NETWORKING ENVIRONMENT 
GCOS software allows remote users, such as terminal operators and applications loc- 
ated in other systems, to access 
- user-defined applications which can be 
- MCS applications which are the subject of this manual 
- transaction programs, written in either COBOL or RPG, under TDS control 
- GCOS communications services, otherwise known as VCAM subsystems, which are 
- RBF6 / FTF6, Remote Batch Facility / File Transfer Facility from/to the Mini 6 
- DJP/ DFT, Distributed Job Processing / DSA File Transfer facility [ 
- IOF including the "pass-through" function operating under IOF 
- TDS, Transaction Driven Subsystem 
~ CARDLESS, also known to the system as READER 
- TILS, Transactional and Interactive Load Simulator 


- OLTD, On-Line Tests and Diagnostics. 


From a transmission standpoint, access to GCOS is through 
« either the Data Communications Controller of the URP 
» or the DN7100 functioning as a front-end processor. 


In both cases, the URP and the DN7100 handle communications over secondary networks 
composed of local, leased and switched lines connected in a tree structure. 


For the current release, the primary network can be configured with the DPS 7 func- 
tioning 


» either as the "host" accessing the remote systems through the intermediary of its 
front-end processor, the DN7100 


e or aS the "satellite" accessing the remote systems directly through its URP. 


The URP, in conjunction with TNS, a function of BINS/HDLC, allows access to 
o the TRANSPAC secondary network and the BINS local network 


» and, a DSA primary network linked either ae virtual circuits over TRANSPAC or by 
- point-to-point HDLC lines. 


| The DN7100, in conjunction with FNPS, can handle communications over 
.» secondary networks, like those supported over the URP 
» and, such types of primary networks as, DSA high level networks and public net- 
works, such as TRANSPAG. 
The diagram opposite shows the extent of the communications interfaces in the DPS 7 
- networking environment. 


For the network control operator's interface with the GCOS communications system, 
see the Network Control Terminal Operations Manual. 


For the system and operations interfaces for terminals connected through the BINS/ 
URP secondary network, including TRANSPAC, see the Terminal Operations Manual. 
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COMMUNICATIONS COMPONENTS — a 


~ GCOS communications eect castes is structured around the fol lowing three main 
DSA layers, namely , 


oe the transport/network - link la atts peeupted by communi cat ions sachisinaed 


which comprises the following modules 


= BINS for” managing the terminals“ in’ ‘the URP local ceework: _ 


- TNS, a function of BINS/ HDLC 
oe for managing the terminals in the TRANSPAC/ URP secondary network accessed 
- either directly over synchronous links or over PAD | 
« and, for providing the direct interface over the DCC of the DPS 7 to the 
primary network thereby enabling the DPS 7 to function as a "satellite" 


- FNPS for interfacing at transport level with the DN7100 as front-end proces- 
sor to the DPS 7 thereby enabling the DPS 7 to function as a "host" in the 
primary network 3 


_e« the session layer occupied by VCAM for providing the interface between the 
communications management on the one side, and the application layer on the 
_ other side, such as 


- handling connection and dialog functions 


- and, allowing direct access to terminals and anaiteaetone without their be- 
ing aware of the communications path « or mechanism used for establishing 
their connection 


- the application layer occupied by 


- communications services, otherwise known as VCAM subsystems, which include 
MCS, being QMON operating with MAM | 


_.= and, user applications which execute oder either MCS or TDS, nemery 
. MCS applications, which are the subject if this manual 
- TDS transaction programs 
« and, batch entries to TDS over the VCAM interface. 


In "Schematic Interfaces of DPS 7 Communications Components", 


¢ communications management and VCAM are shown attached together since they com- 
_ plement each other's functions to operate jointly as the network management 
component. 


« ADM/NASF (ADM file sees are wminoatiy exclusive to each occurrence of the 
FNPS service corresponding to the DN7100 configured on the DPS 7 system, that 
is, for a given DN7100 either service functions are performed on it through 
ADM/NASF (ADM file server) or normal operations are executed on it when its 
associated FNPS service is started 


« the NASF component providing LOG and ASF services functions as follows 
- the LOG service functions like any of the other communications services, — 
such as TDS or MCS or IOF 7 
- the ASF service, however, functions as a communications process group which 
includes all components of communications management and QMON 


« the NAD status table is a list of entries for each communications Peocese 
group 


« tables and pools which can be defined by the user through the CNC utility are 
shown where appropriate. | 
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MESSAGE eee 


MCS i 


MCS 


is a -6COs communications service whose functions. are provided by 


MAM which interfaces user-defined applications written in MCS COBOL or CPL 
with MCS queues 


QMON which ensures “he interface between the queues and VCAM, being the cone 
mon unique interface petwecen all GCOS communications services ae remote u- 
sers. | 


allows the MCS application to communicate with 


terminals connected over secondary networks such as 


- the URP local and TRANSPAG/URP secondary networks 
- the FNPS/DN7100 secondary network 


other MCS applications located in either the same DPS 7 or in other DPS 7's in 


7 the following types of networks 


i either through the BSC2780 link over the BINS/URP veces network 


- or over the primary network accessed by the DPS 7 local system through ei- 
ther the TNS/URP interface or the FNPS/DN7100 interface, see page 1-01. 


Details of connection handling are treated in Section IV. 


Message Access Method 


MAM 


provides such functions as, 


compatibility through MCS with standard communications language elements, 
namely, [$H_]cp, [$H_JENABLE, [$H_]DISABLE, [$H_]SEND, [$H_]RECEIVE and 
ACCEPT/$H_MSGCNT verbs, shown in the form of MCS COBOL and GPL 


access to memory and disk queues, with 4 levels of queue available for input 
checkpoint/restart capability for disk queues 


allocating queues to the user application 


message editing according to the terminal type 


end-to-end protocol between the terminal operator and the user application, 


as provided either by control messages generated by MAM or by the communica- 


tions status generated by BINS 


communication between process groups, that is, communications load modules, 
and between processes, that is, tasks 7 


multitasking within the user application from 1 through 6 user processes. 


A detailed description of MCS is given in Section II. 
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Queue Monitor 


The QMON service workstation is the set of all user-mailboxes handling MCS queues, 
each queve having its own mailbox and bearing the same name. 


The QMON service mailbox is known to GCOS by the system name QMONMBX. 


QMON is in charge of establishing the logical connection 
« between the application-mailbox, associated with the program-queue for input 


e and the terminal-mailbox, associated with the terminal-queue for output. 


Once the connection is established, data exchange takes place as follows, 


e QMON receives the data from the terminal-queue and forwards it to the corres- 
ponding mailbox 


» data forwarded to the application-mai lbox is placed by QMON into the program 
— queues © | 
In addition to connection handling, QMON performs other functions, such as, 


o the transformation of data into and from mark form representation according 
to the transmission mode options specified for the terminal-queue 


° automatic editing on messages sent to the terminal-mailbox according to the 
editing options specified for the terminal-queue, and which affect 


~ message length, beyond which the message is truncated 
- blocking by line and by page. 
Transmission mode and editing options specified for the terminal-queue at network 


generation through the QUEUE command can be overridden by the [$$ MTE network 
control or terminal operator command during the communications session. 


MCS Data Formats 


MCS provides the means of representing data in a number of ways, which frees the 
user from the conStraints of terminal hardware capability, for example, the user 


can specify lower-case letters through symbolic representation, although the ter- 


minal that he uses for data entry does not have the lower-case option 


In addition, the ability to encode control codes in mark form enables the MCS ap- 
plication to deal with the appropriate functions to be generated for a given ter- 
minal. | 


Data processing by MCS is treated in detail in Section III. 
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| Prspeamm ng Terminals 
rerainave operate on a line procedure, which is. ined to establish transmission - 
protocols over the link. | ge | 
| Transmission protocols ‘are seen only at system level and do not affect: the ne 


User visibility in managing terminals of the network is limited to programming 
their control codes by which they function. 


In Section VI, "Programming Terminals", the control codes are given in mark form. 
instead of numeric aoe for ease of mnemonic recognition and Serene cuent in 
alphabetical order. | | 


QUEUE MAINTENANCE 
QMAINT is a systen utility used exclusively for MCS applications for executing 
maintenance actions on memory and disk queues. 
It performs such functions aS, 
« printing the contents of the queue 
» displaying the status of the queue 
° purging the queue 7 
» Filling the queue with defined data. 


For details of QMAINT, see Section VII and Appendix B. 
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The 


SECTION IT 


MESSAGE CONTROL SYSTEM 


Message Control System is the interface 
between MCS applications and terminals accessed over BINS and FNPS. 


between MCS applications residing in the local and remote systems accessed 
either through FNPS or TNS, a function of BINS/HDLC. 


functions are provided by MAM and QMON, as follows, 


MAM provides a uSer-queue access method shared at system level allowing the 
exchange of messages to and from the terminals or applications 


QMON ensures the interface between MCS queues and the basic eommnt caret One 
functions provided by VCAM 


applications can be written in either MCS COBOL or GPL. 
is described in terms of 

communications elements 

queue correspondence 

device handling and message editing 

dialog handling 

data integrity 

Structure of a MCS load module 

communication between local applications 

communication between remote applications 


executing MCS applications. 


| COMMUNICATIONS ELEMENTS | 


The communications eeapnew: are : 
. the communications description area of the application 
~. the communications verbs | 


« the message delimiters. 


- Communications Description Area of the Application 
The CD specifies the interface area between MCS and the user application. 


‘These interface areas contain information about the Rveuee terminals and mess- 
ages on input as well as on output. : | . 


The MCS application must have at least one CD area either for input or for out- 
put. | | | 


If the application requires messages to be sent sat eaesguad: then at least two | 
CD areas must be present, one for input and the other for output. 


CD entries are defined as follows, 
e in MCS COBOL, in the Communication Section 


_. in GPL, by the system primitive H_CD. 


Communications Verbs 


The 5 following communications verbs provide the user interface between MCS on 
the one hand and either the application or the terminals on the other. 


The status of the MCS interface is denoted by key codes described in Appendix D. 


‘MCS COBOL Ge a | function 
primitive | 


H_MSGCNT ascertains the number of messages in a symbolic queue 
identified by the symbolic queue in the input CD area 
of the application. | 


DISABLE H_DISABLE | terminates the logical connection with specified sour-| 
, ces or destinations for data transfers to and/or from 
the terminals. 


establishes the logical connection with specified 
sources or destinations for data transfers to and/or 
from the terminals. 


RECEIVE | H_RECEIVE | requests a message from a specified symbolic queue 
| identified by the Symbolic queue in the input CD area 
of the application. 


directs a message to a specified symbolic queue iden- 
tified by the symbolic destination in the UEEEe CD 
area of the application. | : | | 
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Message Delimiters 
A message is delimited by the END KEY which has the following values 


- "1" for ESI, "end-of-segment'"' indicator 
- '2'' for EMI, "end-of -message" indicator 


- 3" for EGI, Nend-of-group" indicator. 


The message delimiter is coded in its mnemonic form as follows 

. in MCS COBOL, by the statement SEND WITH { ESI | Emr | EcT} 

- in GPL, by the primitive $H_SEND ENDCHAR= | ESI | Emr | EGT} 

The following examples denote the way in which message delimiters are applied, 
namely, 

» from the terminal to the application, in input mode 

« from the application to the terminal, in output mode 


e communication between applications. 


FROM THE TERMINAL TO THE APPLICATION 


° For a non-BSC terminal, the message is delimited by an END KEY value of "3" or 
EGI. 


© For a BSC terminal, 


. each block is terminated by the control code "ETB", "end-of-transmission- 
block"', and is treated by the application as being the END KEY value of "2" 
or EMIT 


the final block terminating the message text is delimited by the control code 
NETX", "end-of-text", and is treated by the application as being the END KEY 
value of "3" or EGI ; 


e where the message is of "zero" length, the END KEY value can be either "2" or 
WW, 


In this case, after issuing a RECEIVE (H_RECEIVE) , the programmer should test 
the values of the following parameters before deciding if there is a message 
to be processed, namely, 


- STATUS KEY 
- TEXT LENGTH 
- END KEY. 
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| FROM THE APPLICATION TO THE TERMINAL | 


7 © For a “non-BSC terminal, 


 « message segments may be isdicaved within the message by an END KEY value of 
"4" or ESI, in which case, each indicator BPpesre: on the terminal | as a "new- 
line" or "line-feed" sequence 


» the message can be delimited by an END KEY value of "2" or mM, or, "3" or 
-EGLI 7 7 


e where the QUEUE is declared with the TWA option at network peneraeion, the 
END KEY value of "3" or EGI is necessary to allow for dialog. 


° For a BSC terminal, 


» the message is transmitted in blocks, the maximum size of which is pepeugeus 
on the type of the receiving terminal 


_e a SEND (H_SEND) with EMI results in the transmission of a data block seams 
ted by the control code "ETB" 


e a SEND with EGI results in the transmission of a data block terminated by the 
control code NETX". | 


COMMUNICATION BETWEEN APPLICATIONS 


The ESI, EMI and EGI delimiters are transmitted by MCS and converted into the ap- 
propriate END KEY values of "1", "2" and "3" respectively, in the destination ey 
area when a RECEIVE “ _RECEIVE) is issued. 7 


QUEUE CORRESPONDENCE 


A queue is a container in which messages are stored and from which messages can 
then be retrieved for later processing on a first-in-first-out basis. 


Depending on application requirements, the queue can be specified either in main 
memory or on a disk file. 


Queue correspondence involves 
« the definition of the physical queue 
- the definition of the symbolic queue 
e relating the physical queue to the symbolic queue. 


Physical Queues 


Physical queues are defined by QUEUE commands at CNC generation, and are identi- 
fied by external-queue-names. 


The physical queue can be 
» either a terminal-queue 


e OY a program-queuee 


TERMINAL QUEUE 

The terminal-queue is an output queue through which a message is sent to the 

terminal. 

The term "terminal-queue" throughout this manual refers to one of the following, 
o the name of the terminal declared in the TERMNL command for a local terminal 


o the name of a DSA-terminal-queue of the format <system-name. mai lbox-name> 
declared in the QUEUE command for an application connected either over the 
secondary network or to a remote system 


e the name of a userid-queue declared in the QUEUE command for a terminal not 
deciared with the AUTO option in the TERMNL command. 


PROGRAM QUEUE 


The program-queue is an input queue through which a message is sent to the MCS 
application. 


The name of the program-queve is the name of the application specified during 
the log-on of the terminal. 
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"Symbolic Queues 

Symbolic queues are Logical queues defined as follows, | 
° in MCS COBOL, in data-name-1 of the cD area (input and output) | 
» in GPL, by QUEUE_NAME in either H _CDIN | or H_CDOUT. 

The queue can be | 

« either input, for message reception 
e or output, for message dispatch. 


In the case of the symbolic input queue, further partitioning into up to 3 levels 
of subqueues can be done as follows, 


« in MCS COBOL, by data-name-2, gaeaeaane: 3 and dat a-name- 4 of the input CD area 
« in GPL, by SUBQUEUE_NAME, SUBQUEUE2_NAME and SUBQUEUE3_NAME in H_CDIN. 


Relating Physical Queues to Symbolic Queues 


The $QASSIGN statement defines the symbolic queue or subqueue and establishes 
its correspondence with the physical queve identified by its "external-queue-name" 
in the QUEUE command at network generation, this correspondence being unique. 
The $QASSIGN statement also defines the processing mode for each type of queue, 
« symbolic input queues 
« Symbolic output queues 
° symbolic input/output queues. 


SYMBOLIC INPUT QUEUES 
A symbolic input queue must be defined for each program- queue from which messa- 
ges are to be received by the application | 
The IN parameter of the $QASSIGN statement serves 
» to identify the symbolic queue as an input queue 
to allocate the program-queve to the current step until step termination. 


No other MCS application may issue a RECEIVE (H_RECEIVE) to the program-queue 
thus allocated. 


2-06 © 


SYMBOLIC OUTPUT QUEUES 


Each terminal to receive output has an associated terminal queue for which a 
symbolic output queue is defined. 


The two ways of defining the symbolic output queue are 


» explicitly, through the $QASSIGN statement 


e implicitly, at terminal log-on. 


Explicit Definition : 


The OUT parameter of the $QASSIGN statement serves 
» to explicitly identify the symbolic queue as an output queue 
» to allocate the terminal queue to the current step until step termination 


The terminal is known to the MCS application exclusively by its explicitly de- 
fined symbolic output queue. 


When a message is received from this terminal, the symbolic source field of 
the input CD (H_CDIN) is updated with the symbolic output queue-name by MCS. 


No other MCS application may issue a SEND (H_SEND) to this terminal queue and 
the terminal cannot be connected to another MCS application. 


Implicit Definition ; 


The symbolic output queue is defined implicitly through the log-on procedure 


of the destination terminal. 


When a message is received from the terminal, the symbolic source field of the 
input CD (H_CDIN) is updated by MCS with the name of the associated terminal 
queue. 


The symbolic source name will be used as the symbolic output queue to which 
messages are sent. 


This method cannot be used if no message is sent from the terminal to the ap- 

plication unless the program-queue is defined with the BREAK option, in which 

case, the logon of the terminal is notified to the application with the status 
key 9D upon RECEIVE (H_RECEIVE). 7 


SYMBOLIC INPUT/OUTPUT QUEUES 


A symbolic 1/0 queue is a program queue and does not have subqueues. 


The INOUT parameter of the $QASSIGN statement serves 


e to identify the symbolic queue as an input/output queue 


e to allocate the program queue to the current step until step termination. 


No other MCS application may issue a SEND (H_SEND) or RECEIVE (H_RECEIVE) to the 
program queue thus allocated. 
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_ Example | 
— of 


| Queue Correspondence 


terminal | program _ symbolic symbolic 
- queues” queues -  subqueues queues © 


application 
TELE 


a . a7 = ap ap . 


INQUIRIES 


application 
COMM 


PRTH - 


aepcnoesen TELE queue relationship 


» each of the program-queues is related to a eerreapondtas symbolic sub- 
queue, ieee, ORD to ORDERS, INQ to INQUIRIES, and RSV to RESERVATIONS. 


« the symbolic subqueues ORDERS, INQUIRIES and RESERVATIONS are associated 
with the symbolic queue INPUT which means that when a RECEIVE (H_RECEIVE) 
is issued to INPUT, its subqueues are scanned until a message is found in 
1 of them, e.g, INQUIRIES, if say, either T1 or T2 is logged on to INQ 


e the symbolic output queues PR1 and PR2 are related to their respective 
terminal-queues PRID and PRIN associated with printers. 
Application COMM queue relationship 


« the direct correspondence of the program-queue STOC to the symbolic queue 
INPUT means that input is received from any terminal logged on to STOC 


« the symbolic output queue PR is related to the er -queue PRTH asso- 
ciated with a printer. 
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DEVICE HANDLING AND MESSAGE EDITING 


An MCS application is.capable of such control functions as, 
« sending control messages 
» being notified of status changes 


» controlling data flow. 


Control Messages 


Control messages are commands or status indicators affecting the MCS applica- 
tion-to-terminal interface, and can be passed between the application and QMON. 


The application views the command like any other meSsage that it sends to the 
terminal. 


The format of the command is 3; 


><CTILxxx, where xxx is a 3-character mnemonic variable for the command 


The types of commands are, 


_e« BRK : interrupt request 
e CNT : indicates the terminal has been connected 
e DIS : indicates the terminal has been disconnected 


» PRG : application request to QMON to purge all existing messages in a ter- 
minal queue; 
this command is given top priority in the queue by QMON 


e RVI : application request to issue a "reverse interrupt" to a BSC line 


procedure terminal related to the specified output queue; 
this command is stored in the queue and processed in sequence 


« SHT : request to application to shutdown. 

When a control message arrives in the destination queue, the count of evaltavre 
messages in the queve is incremented by 1. 

The message type is detected by the "receiver" and reflected by a specific val- 
ue of the STATUS KEY code. | 


On completion of a RECEIVE (H_RECEIVE), both parameters TEXT LENGTH and END KEY 
will be 0. 


The particular use of the commands is as follows, 


e BRK, CNT and DIS commands should only be used for terminal simulation pur- 


poseSe 
These commands when sent to the terminal will be received by the terminal 
but will have no effect. 

The application, on receiving these commands, will be notified by the cor- 
responding STATUS KEY code in the input CD area © 


» SHT command can also be sent by the BT network ePREECr command of the form- 
at : BT program-queue-name ><CTLSHT. | 
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s "Status Changes | 


If the program-queue has been defined with the BREAK option in the QUEUE comnand 
at CNC generation, status changes of the terminal or of the system will be pass-_ 

ed to the application through the STATUS KEY of the input CD area as a result: of 
a RECEIVE (H_RECEIVE). | _ 


The symbolic source identifies the related terminal. 


T£ BREAK has not been specified, then the application will not be notified of a- 
ny events occurring when a RECEIVE (H_RECEIVE) is issued. | 


_. STATUS KEY codes are explained in detail in Appendix D. 
Data Flow Control 
The control of eats flow between MCS and the terminals is through the ENABLE 
(H_ENABLE) and DISABLE (H | DISABLE) verbs functioning as follows, 
_» input without terminal 
« input with terminal 


° output. 


INPUT WITHOUT TERMINAL 


© Enable Input : 


It is coded as follows, 
« in MCS COBOL, by the statement ENABLE INPUT 

_e in GPL, by the primitive $H_ENABLE INPUT. 

The related program-queue specified in the input CD area is "enabled", i.e., 
« connection requests from the terminals can now be accepted 


. terminals defined with AUTO and ASSIGNed to one of the queues or subqueues 
will be immediately connected when the RT network control command is issu- 
ed, if required. 


° Disable Input : 


It is coded as follows, | 
. in MCS COBOL, by the statement DISABLE INPUT 
-» in GPL, by the primitive $H_DISABLE INPUT. 
The related program-queue specified in the input CD area is "disabled", that 


e no more connections to the queue can be accepted 
» any terminals previously connected are now disconnected. 


The application may continue to empty the queue through RECEIVEs (H _RECEIVEs) 
and when the queue is empty, the STATUS KEY is flagged as "disabled". 
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INPUT WITH TERMINAL 


© Enable Input with Terminal : 


It is coded as follows, | 
» in MCS COBOL, by the statement ENABLE INPUT TERMINAL 
o in GPL, by the primitive $H_ENABLE INPUT TERMINAL. 


The terminal whose name is specified as the symbolic source in the input CD a- 
rea can Start or resume input to the queue to which it was connected. 


| 


Disable Input with Terminal : 


It is coded as follows, 
o in MCS COBOL, by the statement DISABLE INPUT TERMINAL 
» in GPL, by the primitive $H_DISABLE INPUT TERMINAL. 


The terminal whose name is specified as the symbolic source in the input CD a- 
rea can no longer transmit in input mode. 


OUT PUT 


"Enable output" and "disable output" only apply to terminal queues. 
If either verb is applied to program-queues, no action results. 


© Enable Output ; 


It is coded as follows, 
> in MCS COBOL, by the statement ENABLE OUTPUT 
o in GPL, by the primitive $H_ENABLE OUTPUT. 


The related terminal-queve specified in the output CD area is "enabled", that 
is, output flow will be resumed to the terminal whose name is specified in the 
output CD area. 


© Disable Output : 


It is coded as follows, 
° in MCS COBOL, by the statement DISABLE OUTPUT 
e in GPL, by the primitive $H_DISABLE OUTPUT. 
The related terminal-queue specified in the output CD area is "disabled", that 
is, | - | 
e output flow from the queve to the terminal is suspended 


» the application may continue to send messages to the queue. 


ENABLE anee 


‘ENABLE INPUT with input CD area 
_ specifying the related pregten 
queue QA, 


The queue QA is enabled", whereby 
» connection requests from termi- 
nals to QA and its subqueues 

are accepted 

terminals with AUTO aad ASSIGN 

are immediately connected to QA 

and its subqueues when the RT 
network command is issued. 


ENABLE INPUT TERMINAL 


ENABLE INPUT TERMINAL with input 
CD area specifying the terminal Tn 
as the symbolic source. | 


The terminal whose name is speci- 
fied as the symbolic source in the 
input CD area can start or resume 
input to the queue QA to which it 
was connected. | 


@e@ee2eoe 6064068 


Other terminals continue to remain 
in their original states. 


ENABLE OUTPUT: 


“ENABLE OUTPUT with output CD speci- 
fying the terminal Tn as the desti- 
nation of the output flow from its 
related queue. 


Data flow can now resume from: the 
queue specified in the output CD a- 
rea to its related terminal. 


Both the terminal and its related 
queue bear the same name, this cor- 
respondence béing unique. 


A 


; @#e92¢6¢0900809820806 


nd 
na 
nd 


938898 @e006206606 


@eo8e08290@6 


. 
| se 
te 


Examples 


of 


DISABLE 


DISABLE INPUT 


DISABLE INPUT with input CD area 
specifying the related program | 
queue QA. 


The queue QA is "disabled", where- 
by 


e no more connections to the 
queue can be accepted 


» any terminals previously con- 
nected are now disconnected. 


DISABLE INPUT TERMINAL 


DISABLE INPUT TERMINAL with input 


CD area specifying the terminal Tn | 


as the symbolic source. 


The terminal whose name is speci- 
fied as the symbolic source in the 
CD area can no longer transmit in 
input mode to the queue QA to 
which it is connected. 


Other terminals continue to remain 


in their original states. 


DISABLE OUTPUT 


DISABLE OUTPUT with output CD spe- 
cifying the terminal Tn as the 


destination of the output flow 


from its related queue. 


The related queue Tn is "disabled" | 


output flow from the queue to 
the terminal is suspended 


the application may continue to 
send messages to the queue. 


DIALOG HANDLING _ 

— Dialog ‘between the appt vectton and he ceraival is handled according | to the Eye | 
of application, namely, | 7 

_« Non-interactive: ‘applications > 


« interactive applications. 


Non-interactive Applications 

A typical non-interactive ORE teense involves the Following BEASESs 
e« data entry | 
e batch processing 

-. data distribution. 


These stages are independent of each other, and the only relationship Eney bear 
to each other is that they are consecutive in the order shown, 


The dialog between the terminals and their related queues, and between the ap-. 
plication and the data entry queues is not restricted, that is, data flow is 
permirees in either ai receion: 


DATA ENTRY _ 
“The sonicncicn may be absent at ie time when data is collected from the termi - | 
nals into the program- queues. | | , | 


Only the communications ecapenente.. BINS or -FNES, one QMON, need be present in 
System and the terminals need be connected to the Pree ramedueses for data entry 
to take place. | 


In order to allow the terminal to enter data without the application being pre- 
sent, the program-queue must be defined as a data entry queue, that is, the TWA 
option must be omitted from the QUEUE command at CNC generation 


BATCH PROCESSING 
When all the data has been entered, the application can begin processing during 
off-peak hours, say, late at night. 


Processing involves updating files and PPEepar ins i data to be placed into 
the terminal queues. 


-QMON plays no part in batch processing and is therefore absent from hes system 


DATA DISTRIBUTION 


QMON empties the output data in the terminal-queues to the respective terminals 
when these terminals are activated. 


The application plays no part in data distribution and is therefore absent from 
the system ; | | | | 
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Examp le 
of 
Non-interactive Application 


DATA ENTRY 


All terminals can enter data at will 
to the data entry queue which is a 
program-queue declared without the 
TWA option. 


Only BINS or FNPS, and QMON need be 
present in the system. 


The application does not need to be 
| present in the system since the data 
entered is not immediately process- 

ed. 


@eeoeeeed e8 © 


A 


FE eee BATCH PROCESSING 
| [ones pees Data collected from the terminals 
previously entered at the "data en- 
try'' stage can now be processed at a 
time when the terminals have ceased 
transmission. 


Processing involves updating files 
and preparing output data to be put | 


[| | | into the terminal queues for later 


QMON is absent from the system 


DATA DISTRIBUTION 


When the terminals are activated, 


(cata entry queue! ! ovon outputs the results to the res- 
| pective terminals. 


| The application plays no part in da- 
| ta distribution and can therefore be 
'| absent from the system 


|| The dialog between the terminals and 
| their queues, and -between the appli- 
cation and-the data ent ey queues is 
| not restricted. 


}| terminal queue 


_ Interactive re Applications | 


Typical interactive | applications are “either transactional or inquiry-response 
applications. | | , | | 


The TWA option of the QUEUE. command when declared ‘at NG: paneacion: for: the eet 


ociated queue determines the way in which the dialog is handled by the system 


An example of an MCS application testing the TWA option is given in Appendix A. 


WITH TWA OPTION 

The program-queue defined with the TWA option enables dialog between the appli- 
cation and the terminal on a message basis. | 

On connection, the terminal has the "curn", that is, the right to transmit. 


A message transmitted by the terminal is delimited by the END KEY value of "3", 
denoting EGI. | 


The system, on detecting EGI in the getuiaais message, then transfers the "turn" 
to the application. | . 


The application can then transmit using the SEND (H_SEND) verb. 
Transmission by the application is performed as follows, 


« several messages delimited by the END KEY value of "2", denoting EMI, can be 
transmitted and the "turn" is still retained by the application | 


° a message delimited by EGI transfers the "turn'' to the terminal. 


The terminal's "turn" can be overridden at any time by the application. 


WITHOUT TWA OPTION 


The program-queue defined without the TWA option enables the terminal to trans- 
mit messages at will. 


In this case, the prog neur queue acts like a data entry queue. 


Example of 


Interactive Application 
with TWA Option 


i Terminal Tn enters a message 
into the program-queue PROLL 
which has been declared with 
the TWA option at CNC gener- 
ation. | | 

, . The message is delimited by 

| RECEIVE - an END KEY value of "3" de- 


. noting EGI. 
: 


2 The message is RECEIVEd by 
the MCS application for pro-| 
cessinge | 
In the meanwhile, the "turn'' 
is given to the application 


3 After the MCS application | | 
has processed the message, 
it can SEND several messages 
delimited by EMIs to the | 
terminal queue Tne 
For as long as messages from| 
the application are delimit- 
ed by EMIs, the application | 
retains the "turn". 

Messages from the terminal 
are discarded. 


4 MCS starts transmission to 
the terminal Tn. 


5 The last message in the 
stream to be sent by the ap- 
plication is delimited by 
EGI. . 

Although EGI transfers the 

"curn'' to the terminal Tn, 

the application can still 
override the terminal. 


6 When the terminal Tn receiv- 
es the last message, it can 
then enter another message 
to the application 
If overridden, the terminal | 
Tn can transmit later. 
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DECLARING AN APPLICATION "AUTOMATIC" | 


An automatic application is one which is automatically started 

~ if MCS finds that its associated queues contain data still to be processed a 
e and, if the application, for whatever reason, is no monger executings 

The facility’ for declaring an application’ automatic" is ‘uaicaced: at network gen- 
eration by both the following CNC options, 

-« the INIT parameter of the QUEUE command specifying ‘he name of the Boutin ten 


» and, the APPLIB parameter of the GENQMON command specifying the cataloged lib- 
rary of application JCL eee of which the referenced a cada is a mem- 
ber. 


At run-time, if any queue of such an application declared "automatic" contains da- 
ta for processing, and if the application has stopped executing, QMON 


« identifies the application of the queue concerned from the argument of its INIT 
parameter 


« retrieves the JCL subfile of the referenced spe rieetaon from the cataloged lib- 
_ vary specified as the argument of the APPLIB ReLoueree 


- and, Starts the Sppsicaceons 


The sdvantares of declaring an application “automatic” are that a 
« the application does not depend on the system console operator to be submitted 


- and, even if the application were abnormally terminated either through a TJ sys- 
tem console command or as the result of a system failure, the application will 
be automatically resubmitted without further intervention of the operator. 


The "automatic" facility is useful for an "interactive" application which must be 
present in the system for data to be entered and dispatched. 


DATA INTEGRITY + eevee & 


a 
aor 


e retention of messages in terminal-queues 
« retention of messages in program-queues 
e checkpoint and restart facility 


eo control of message and queue overflow. 


Retention of Messages in Terminal Queues 


When an MCS application issues a SEND (H_SEND), a STATUS KEY assigned to the act- 
ivity is set to a value which can be tested by the user as follows, 


- if the STATUS KEY denotes an incident, the message is not released 


e if the STATUS KEY denotes normal conditions, then the message is released to 
the terminal queue under the charge of the system 


When the receiving terminal and its related communications path, over either 
BINS or FNPS, are active, MCS attempts to transmit the message from the terminal 
queve to the corresponding terminal in the following way, 


e if transmission is successful, the message is deleted from the terminal 
queue : 


e if transmission is not successful, several retries are attempted, according 
to the number specified by the user 


. if transmission is persistently unsuccessful, the terminal queue is "closed" 
but the message is retained in the queue. | | 


The message is retained in the queue until one of the following occurs, 


e it is ultimately and successfully transmitted along the communications path 
to the terminal 


» a shutdown is effected, whereby the message will be lost if the terminal 
queue is a memory queue or disk queue specified without the RESTART option 


« a CNC step is executed, in which case, the message will be lost, even if the 
terminal -queve is specified with the RESTART option 


» ISL with REFORMAT option is performed, in which case, the message will still 
be lost, even if the terminal-queve is specified with the RESTART option 


Message retention in terminal-queues applies under such conditions as, 
e QMON "abort"! | 


e system crash. 
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Retention of Messages in Program- | 


A message which is sicceseeu tty placed in a program-queue is retained until one 
of the following events occurs, | 


- it is successfully retrieved by the application for processing 


» a shutdown is ‘effected, “whereby the message will be lost if the program- ee 


queue is a memory queue or a disk queue specified without the RESTART option 


e a CNC step is executed, in which case, the message will be lost, even if the 
_ program-queue is specified with the RESTART option 


e ISL with REFORMAT option is performed, in which case, the message will still 
be lost, even if the program-queue is specified with the RESTART option. 


Checkpoint and Restart Facility 
The facility allows the following. functions, 


« disk queues, which can be either program-queues or terminal-queues, specified 
with the RESTART option, are journalized and therefore can be "rolled back" 
to allow for recovery, as follows, 7 , | 


~ the head-of-queue of a program- queue is "Mrolled back" to the last welee 
checkpoint 


- the head-of - queue of a terminal-queue - is "rolled back" to the last un- 
transmitted message 7 7 | 


. disk terminal-queues specified with the CTLRST sotioa allow for controlled 
"restart" for retransmission 


. the user application specified ite the ‘REPEAT option in the $STEP statement 
can be restarted. 7 


The conditions for which the facility is used are, 
» step abort — 
¢ System crash. 


The purpose of the facility is to ensure that the queues, the eapiieseton: and 
all user files are in the same State when restart takes place, as they were at 
the last checkpoint. — 


If checkpoints have | not taken Sines. then restart is at the pegtapine of the 
step. 


The checkpoint and restart facility is dealt with under the following topics, 
« issuing checkpoints 
« implementing checkpoints 


-e conditions for restart. 


ISSUING CHECKPOINTS 
Only MCS monoprocess application with disk queues can issue checkpoints, as foll- 
OWS , 

e in MCS COBOL, by the declarations, 


- RERUN ON CHECKPOINT FILE entry in the I-O-CONTROL paragraph, through 
which checkpoints are taken at specified intervals of records processed 
for a particular file 


- CALL statements to the H_CK_UCHKPT run-time package, by which checkpoints 
are taken at appropriate places in the application 


e in GPL, by the primitives, | 


- $H_FD specifying the CKPTLIM keyword, whereby checkpoints are taken at 
specified intervals of records processed for a particular file 


~ $H_CHKPT which allows checkpoints to be taken at appropriate places in 
the application. 


The program-queue is journalized if it has been specified as follows, 
e with the RESTART option in the corresponding QUEUE command at CNC generation 


e aS an input queue, by either the IN or INOUT parameters of the corresponding 
$QASSIGN statement. 


Journalization is performed on the disk queve itself and no additional file space 
needs to be allocated. 


A journal is considered "active" for a given program-queue only for the duration 
of the MCS application step. 


Checkpoints have no effect on terminal-queues except for terminal-queues corres- 
ponding to anHL64 CPU, to be discussed later on in "Communication between Remote 
Applications", see page 2-31. 


IMPLEMENTING CHECKPOINTS 


For program-queues described with the RESTART option, disk space related to mess- 
ages will be released only at checkpoint time or on termination of the MAM appli- 
cation. 


The user must take this mechanism into account, 


» when defining the size of such program-queues in the corresponding QUEUE com- 
mands at CNC generation 


e when deciding the frequency of checkpoints in his application. 


When reading messages from a program-queue, the “head-of-queue" marker points to 
the next message to be RECEIVEd by the application. 


The "checkpoint" marker points to the position of the "head-of-queue" marker at 
the time of the last checkpoint. 


In the case of application "'restart", the "head-of-queue'"' marker is then restored 
to the "checkpoint" value. | | 
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Queue Status | 


| after - 
Taking Checkpoints © 


TO 7 | | 7 At time TO, both "checkpoint" and 
a T “head-of- queue" markers point to mes- 
sage Ml. | 


It is assumed that the queue holds 4 

| messages, and that at the start of 

"checkpoint" - “head-of-queue'"! the application, it is occupied by 
marker marker messages M1, M2, M3 and M4. 


Tl 


MCS 
application 


"checkpoint"  Nhead-of-queue"' 
marker marker 


At time T1, the situation concerning the queue status is, 
» the messages RECEIVEd by the MCS application are M1 and M2 
e the "head- of- Pap eRe? HaEREe has moved aEcmiaiee es M1 to point to message 
M3 
« the "checkpoint" marker has not moved and still points to mentee Mi. 


RECEIVE 
| MCS 
application 


"checkpoint" _ “"head-of-queue" 
marker marker 


At time T2, when the MCS application has successfully processed messages M1 
and M2, and taken a checkpoint, the situation concerning the queue Status is, 
« the "checkpoint" marker has moved from message M1 to point to message M3 
e messages M5 and M6 now arrive in the queue displacing messages M1 and M2 

« the MCS application has now RECEIVEd messages M3 and M4 
e the "head-of-queue" marker has moved from meSsage M3 to point to message 
M5. | 


If an abort occurs, the queue status at reStart will be, 

e the "head-of-queue'' marker will be "rolled back" to the position of the 
"checkpoint" marker pointing to message M3 

« the "checkpoint" marker, however, still points to message M3 

« the messages to be RECEIVEd by the MCS eppreeae ton, WEE! be M3 through M6. 
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CONDITIONS FOR RESTART 


A job step can ae ae be restarted if the $STEP statement contains the REPEAT para- 


metere 


In this 
or from 


case, the job step can be restarted either at the beginning of the step 
the latest checkpoint taken. 


© Restart after Step Abort : 


Queues asSigned to the step with the RESTART option, are "rolled back"! to the 
previous checkpoint if the step is restarted. 


Otherwise, they are left in the state they were at the time of the abort, in 
which case, they can be printed out by the use of the QMAINT utility for de- 
bugging purposes. 


All 


other queues are left unchanged. 


© Restart after System Crash ; 


Queues assigned to the step are treated as follows, 


The 


terminal and program-queues specified without the RESTART option are re- 
initialized 


terminal-queues defined with the RESTART option are restarted from the 
next message following the last message successfully transmitted. 


‘If the crash occurred during transmission, the queue is restarted with 


the message that was being transmitted at the time. 


Restart of terminal-queues with the CTLRST option, is dealt with in 
"Communication between Remote Applications", see page 2-31 


program-queues with an active journal are "rolled back" to the last 
checkpoint taken or to the beginning of the step 


program-queues with the RESTART option but without an active journal, 
that is, queues not assigned to the MCS application at the time of the 
system crash, are restarted from their current states 


programming techniques to consider for restart after a system crash are, 


the MCS application restarted from the latest checkpoint will process 
the first message in the symbolic queue. 


This message may have been already processed and eaueee the delivery of 
an output message. 


In this case, the output message will be duplicated. 


if the application wants a terminal to be aware of its checkpoint, it can 
now send a mesSage to the terminal indicating the checkpoint number. 


On restart from checkpoint "i", the application should send a message to 
the terminal indicating restart from checkpoint "i", so that the terminal 
operator is aware of the repetition of messages. 
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° Restart tees ee Crash. (continued) 


« mesSages being transmitted at the time of the crash should be retrans- 
mitted by the terminal operator at reStart. 


‘The application should check for redundant. messages by. ensuring that all 
| input messages should include sequence numbers. 


. if the program-queue needs to be purged following a restart, the appli- 
_ cation may do so by issuing as many RECEIVEs as the message count. 


© Restart at MAM initialization 2 


The eneen of action for the system console operator ihen starting up MAM in 
the case where disk queues existed for the preveows Session are, 
e MAM = YES | _ 
~ all queues without the RESTART option are purged 


- terminal-queues with the RESTART option commence following the mess- 
age successfully transmitted or at the message being transmitted 


- program-queues with the RESTART option commence from 


- either the ene ae els dueuer marker for normal termination of the 
session 


- or the last "checkpoint" marker, if the following. conditions are 
fulfilled, | 


- the queues have an “Nactive! journal 


- the session terminated abnormally. 


» MAM=NO. 


This action is taken in cases where MAM is not required to save start-up 
time and space in system resident memory. 


- unless a new CNC session is run to generate the autwork, MAM is not 
available > 


- the contents of the disk queues remain in the state they were at the 
time when the session ce rminaeers 
e MAM= REFORMAT 


- MAM start-up suerattons are performed whereby all queues are reini- 
tialized 


- the disk queue file is reformatted using the copy of the communi ca- 
tions system tables in backing store. 3 
The programming techniques to consider for restart at MAM initialization 


are, 


° program- queues can be filled during a session when no MCS applications 
are active , 


« the contents of such queues can then be retrieved in ‘Subsequent sessions 
when MCS applications are executed. 
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Control of Message and Queue Overflow 


When the message size limit or queue capacity is exceeded, an overflow condition 
results which causes the STATUS KEY of the CD entry to be updated with the appro- 
priate return code to inform the user. 


The list of STATUS KEY codes is given in Appendix D. 
CD entries are defined as follows, 

e in MCS COBOL, in the Communication Section 

e in GPL, by the system primitive H_CD. 


MESSAGE OVERFLOW 


The maximum message length is restricted to 3053 bytes. 


Although the default value for QDBLKSZ is 400 bytes, it is advisable to declare 
at least 500 bytes when preallocating the disk queve file. 


Specifying a QDBLKSZ value of less than 400 bytes results in.a warning at CNC 
execution time and the value is then overridden by the default value of 400 bytes. 


See "Preallocating a Disk Queue File"-on page 2-43. 


When message length, including control codes as hexadecimal values or in mark 
form, is exceeded, the excess portion of the message is truncated to 2432 bytes. 


The STATUS KEY code setting is as follows, 
e 94, MSGOV "message overflow'' for the sender 
e 94, NOTALL for the receiver. | 

The maximum message size should be defined by the application according to, 
« the size of the terminal display 


e the allowance to be made for transmission errors. 
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QUEUE OVERFLOW 


When there is insufficient space in a queue to contain a message sent to it or to 
- handle 1/0 transfers, the “message is discarded and the STATUS KEY is set to the A 
appropriate value. | an 7 


| When a queue overflow condition occurs on a _ SEND (H SEND), the spptiest ton should 
issue a "call" to the timer before attempting to re-execute that SEND. 


The "call" to the timer is performed as follows, 
« in MCS COBOL, by the statement CALL to the run-time package 1 H_TM | USETTM 
e in GPL, by the system primitive H_SETELT. 


STATUS KEY code peecue for the relevant ecules en indicating the type of queue 
overflow is, : 


e 91, SPACENAV, space not available, for the sender to be notified of the lack 
- o£ space in the disk queue | , 


» 92, BUFNAV, buffer not available, for the sender and the receiver to be noti- 
fied that there is insufficient memory space to handle a disk I/0 eoceet ton 
during a message transfer 


e 95, NOTALL for the Benger to be notified that the number of memory blocks is 
insufficiente | | 
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STRUCTURE OF AN MCS LOAD-MODULE 


An MCS load-module comprises 1 through 6 user processes which are basically equi- 
valent to tasks and are linked together by the Static Linker, see "Executing MCS *. 
Applications", 


Each process is associated with an application or "run-unit". 


The system handling of the MCS load-module depends on whether the module is mono- 
process or multiprocess. 


Monoprocess Load-Module 


The system executes a call to the entry point of the monoprocess load-module 
specified by the user. 


On termination of the process, a call is made to MCS to perform housekeeping 
functions, whether the process terminates normally or abnormally. 


The program is terminated as follows, 
e in MCS COBOL, by the EXIT PROGRAM statement 
e in GPL, by the RETURN statement. 


Multiprocess Load-Module 
The system procedure STUSERS starts each of the STUSERn processes, where n ranges 
from 1 through 6. 


Each STUSERn executes a call to the application through a user-specified entry 
point at linkage time. 


On termination of the process, STUSERn calls MCS. to perform housekeeping func- 
tions before returning control to STUSERS. 


When all the processes have terminated, and all housekeeping functions have been 
performed, STUSERS terminates automatically. 


The constraints for the multiprocess load-module are, | 


. the programmer must synchronize accesses to shared files, see "Communication | 
between Local Applications" | 


« the checkpoint and restart facility is not available 


» only one process can execute the ACCEPT (H_GET) and DISPLAY (H ene verbs to 
gain access to the standard SYSIN and SYSOUT files. 


In GPL, the user has the option of either using STUSERS as a system procedure or 
coding his own procedure whereby he can explicitly declare the start of each pro- 
cesSo 


This facility enables the GPL user to initiate secondary tasks not contesnTne MCS 
primitives. 


This topic is treated under "Executing MCS Applications", see page 2-43. 
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| COMMUNICATION BETWEEN LOCAL APPLICATIONS 


The term "local" means that the applications are in the same central processor, | 
whereby communication is established by manipulating program- queues. 7 


The program-queue whose name is to. appear inthe symbolic: source. of the: destina- 


tion input CD area is specified by the keyword REPLY in $QASSIGN OUT. 
The ENABLE (H_ENABLE) and DISABLE (H_DISABLE) verbs are not effective. 
The 3 types of local communication are, | 

« application-to-application communication 

e« application communicating with itself 


« communication between processes of a multiprocess application 


_ Application-to-Application Communication 
The assignments in the $QASSIGN statements required to allow such exchanges are, 


Application A 


» the symbolic queue INPUT must - correspond to the program- queue QA for input, 
that is, specified with IN 


e the symbolic queue OUTPUT must correspond: to the program-queue QB for output, 
that is, specified with OUT and peeve 
Bierce en B | | | 


e the symbolic queue INPUT must correspond to the program- queue QB for input, 
that is, specified with IN | 


. the symbolic queue OUTPUT must eee to the program-queue QA for output, 
that is, specified with OUT and REPLY =QB. 


Application Communicating with Itself 


The assignment in the $QASSIGN statement required to ellow such an exchange is, 


e the symbolic queve INPUT to correspond to the program-queue QA for input as 
well as output, that is, to be specified with INOUT and REPLY =QA, 


The application will then communicate with itself in the following stages, 
« it will act as a terminal to fill the program-queue QA 


» it will then RECEIVE messages from the same program- queue QA exactly as it 
would RECEIVE messages from any terminal connected to it. 
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Examples 
F of 
Communication between Local Applications 


Application-to-Application 
Communication 


Application A receives as input 
messages supplied by B, and 
vice verSae 


For Application A, the symbolic 
queue OUTPUT must be specified 
with REPLY =QA. 


1 For Application B, the symbolic | 


queue OUTPUT must be specified 
with REPLY = QB. 


Application Communicating 
with Itself 


Prva: 4 | Application acts as a terminal 


queue 3 | to fill the program-queue QA. 


It then receives the messages 
from QA in the same way as it 
receives messages from any ter- 
minal connected to ito 


| The Symbolic queue INPUT must 
ibe specified with REPLY =QA to 
allow for such an exchange. 


Communication between Processes 
of a Multiprocess Application 


Process A issues a RECEIVE to 
program-queve STORE through the 
symbolic queue FILE. 


When acknowledged, Process A can| 
“Alaccess the "shared" file. 


Process A then SENDs a message 
to STORE to notify Process B 
that the "shared" file is free. 


Process B can access the file. 


- Communi cation between Processes of a Multiprocess Application 


Such commini cation involves essentially the sharing of a file or ‘files between 
processes of the same application. | : 


The . 
the 


“The 


for 


The 


plications belonging to different steps by a a a the SHARE es in the re- | 


assignment in the $QASSIGN ‘statement | required to > regulate eychaaces between 
processes accessing a "shared" file is, 


the symbolic queue FILE to correspond to the program-queue STORE for input as 
well as output, that is, to be specified with INOUT. 


programmer is responsible for synchronizing och accesses to the "shared" file 
multiprocess applications. | | — 


same mechanism can also be applied to a queue providing access to several ap- 


levant QUEUE command at CNC generation. 


The 


‘Stages in implementing file sharing are, 


at step execution, the application must first prime the program-queue STORE 


with a message which serves to notify the first preeee® wishing to access the 7 
"“shared'' file that is available: | , 


the first process, process A, say, can then issue a RECEIVE (H_RECEIVE) to 


the program-queue STORE through the symbolic queue FILE. 


When the message is RECEIVEd, process A has access to the "sShared'' file. | 


when process A has finished with the "shared" file, it SENDs a message to the | 
program-queue STORE to notify any other process, process ‘By Say, vtenane to 
access the "shared" file that it is now available. 
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See ON BETWEEN REMOTE APPLICATIONS 


The term "remote" means that the applications are in different central processors 
which are either linked through a BSC line procedure over the BINS/URP interface 
in the secondary network, or connected in the primary network over either the 
TNS/URP interface or the FNPS/DN7100 interface through the HDLC X.25 link. 


The implementation of the BSC2780 line procedure is treated in detail in Section 
V "Line Procedures". 


Information on the TNS/URP and FNPS/DN7100 interfaces is given in detail in Sec- 
tion IV "Connection Handling". 


The following text is a description of how the BSC2780 link is handled. 


Communication is established at any given time by only two applications at either 
site by means of describing the other site as a BSC terminal with the following 
attributes in the respective TERMNL command at CNC generation, 


e terminal-type being CPU 
e AUTO 


e ASSIGN=program-queue, for which a QUEUE command bearing the name of <1 ee . 
gram-queue'"' must be declared in the same CNC generation. 


Communication between remote applications is described in terms of 
e implementation | 
e recovery on the emission side 
» recovery on the reception side 


Implementation 


The operation of the BSC link-up depends on such factors as, 
e the nature of the communication, that is, 
- either interactive communication 
- or unidirectional communication 
. the recovery protocol. 
The implementation of the link-up is achieved by 
e the CNC description of the network 
e the run-time JCL 


0 the message flow between the sender and receiver applications. 
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Setting up 
 . Communication 
between Remote Applications 


~ Queue Structure 


Application A (sender) | | Application B (receiver) 


symbolic physical | _ physical symbolic] 
queues queues _ MCS 


| cS 
program | _ oe Q ‘program 
eh) ESS 
| , 0 
N 


terminal ae terminal 


{ours [8] ears | Cae) _ our 


queues queues — 


CNC Description for BSC Link-up 
Site 1 a . - Site 2 


LINE LNnn CLOSE; | | LINE LNnn CLOSE; 
STATN STA1 13 | STATN STA2 2; 


TERMNL TB HL6O4 CPU ASSIGN =QA TERMNL TA HL64 CPU ASSIGN = QB 
| AUTO ; | AUTO ; 


| QUEUE QA «ee RESTART; | QUEUE QB «ee RESTART ; 
QUEUE TB .-. CTLRST; QUEUE TA e+e CTLRST;— 


e 


Run-time JCL 


QASSIGN IN1 QA IN; QASSIGN IN2 QB IN; 


QASSIGN OUT1 TB OUT; | QASSIGN OUT2 TA OUT ; 
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NATURE OF COMMUNICATION 


®° Interactive Communication 2 
Exchanges of data will take place in both directions successively from the 
sender to the receiver, and vice versa, the applications reversing roles. 


However, before the applications can be started up, the link-up must first 
be established. 


° Unidirectional Communication :; 
As in the case of file transfer, the sender application can be started up 
first, provided that 
» its output queue is on disk 


e and that the disk has enough space to contain the entire file to be 
transferred. 


In some cases, the rate at which the data is sent exceeds the rate at which 
it is received. ; 


This condition happens when the rate at which the output queue is being fill- 
ed in by the Sender application is greater than the rate at which the same 
output queue is being emptied to the receiver application. 


When this occurs, as in the case of file transfer from magnetic tape, the 
sender application will encounter "queue-overflow' incidents. 


To avoid such incidents, the sender application should issue a call to a sys- 
tem procedure to temporarily suspend transmission of data for a specified 
lapse of time before attempting to issue another SEND to the output queue. 


In the meanwhile, transfers of data from the output queue to the receiver 
application can proceed unaffected. 


A "loop"' on the SEND (H_SEND) has the effect of a temporary suspension, al- 
though this method is not advised as it takes up too much CPU time. 


RECOVERY PROTOCCL 

Where the link-up between two remote applications involves a one-way transfer, 
recovery protocol uses the system checkpoint and restart facility. 

The sender application emits a recovery mark each time it takes a checkpoint. 


When the receiver application receives the recovery mark in the form of a control 
message, it, in turn, takes a checkpoint. 


Restart is always initiated by the sender application. 


In order to implement the restart facility, the following options must be de- 
clared in the appropriate QUEUE commands at CNC generation, 


© program-queues must be defined with the RESTART option 
o terminal-queues must be defined with the CTLRST option 


2-33 


Communication between Remote Applications 
| Programming Message Flow 
between Sender and Receiver — 


Site 1. 


Site 2 | 
Application A (sender) > syptication B (receiver) 
| @sranr « Call checkpointe 

Test value of MODE. 
[$u_]SEND ("><cTLCKPOO") EMI 


before SENDing data, A takes first 
checkpoint to SEND control message 


showing checkpoint numbered "00" 
(zero). 


Kiba JRECEIVE 
Call checkpointe 


first message RECEIVEd is check- 
| wm. Bm point "00"; B takes its own check- 
a | point; both checkpoints have init- 
(@)($H_]SEND (data) femt|ecr} ial values "00% 

A SENDs 1 or more files terminated 
by the appropriate indicator.. 


| @ [$_]RECEIVE 


| - . | B RECEIVEs data from A as a stream. 
~@ceall ceacksotnt: | | 
Test value of MODE. | 
[$H_]SEND ("><CTLCKPnn") EMI ~ 


A takes sequentially numbered 
checkpoints to SEND as control 
messages. 


(c) [$H_]RECEIVE 
Call checkpoint. 


When B RECEIVES successive check- 
points, it takes its own check- 
points. The result is that the 


7 ' | sets of checkpoints of A and B 
G)[$H_]sEND (data) }Emz|Ecr} match 1-for-1. 


A continues to SEND data in a 
stream. 


|@ [$H_]RECEIVE 
| | | B continues to RECEIVE data. 
() call checkpoint. ae 

Test value of MODE 

[$H_]SEND ("><CTLCKPnn"') EGI 


A takes final checkpoint and 


SENDs the control message termi- 
nated by EGI. | (e) [$H_]RECEIVE 


| Be La hem 
-MODE=00— | | 


: When B RECEIVES EGI, it takes its 
| ©) End of normal transmission. Sonar eee cenit 
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Recovery on the Emission Side 


Example of 


Restart of Application on Incident 


| Site 1 Site 2 
Application A (sender) ———————_———- Application B (receiver) 


Transmission has so far been normal and free of errors, but has not yet ter- 


minated. 


@)[$_]SEnD (data) {=m1|zcr} 


A continues to SEND data in a 
stream 


(2) Call checkpointe 
Test value of MODE. ~ 
$H_ SEND ("><cTLCKP(4i)") EMI 


© [s4_]sen (data) {EMI |EGI 


step abort 
| or 
| system crash | 
| occurs 


G)Test value of MODE. 


MODE # 00 | 


[$u_Jsenp ("><crirsr(ii)") EMI 


The number of the "restart" con- 
trol is the same as the last va- 
lid checkpoint. 


G) [$H_]SEND (data) }EM1|EcT} 


| (a) [$H_]RECEIVE 


B continues to RECEIVE data. 


© [$H_]RECEIVE 
| Call checkpoint. 


The number of the checkpoint ta- 
ken by B is also "ii", | 


| © [$H_]JRECEIVE 


At the time of step abort or sys- 
tem crash, the data RECEIVEd by 
B is in an indeterminate State. 


| @ [$H_JRECEIVE 
: When B RECEIVEs the "restart" con- 
trol, it sets the STATUS register 


to 10,000 to denote "step abort" 
or "system crash’, 


EXIT PROGRAM : MCS COBOL 
RETURN : GPL 
(e)[$H_]RECEIVE 
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_ Recovery on the Baission Side 
Recovery of transmission on the emission side involves, 
- « taking checkpoints 7 

- sending control messages © 

e reStarting after a step abort or system crash 


» reStarting after a line failure. — 


TAKING CHECKPOINTS 


Each transmission is started with a checkpoint call. 

On return of the call, the output parameter MODE is tested as follows, 
« MODE=00, for normal error free transmission | 
« MODE#00, when a step abort or system crash has occurred. 

Taking checkpoints is performed as follows, 

-« in MCS COBOL, by a call to the H_CK_UCHKPT run-time package 

. in | GPL, ae the aa H_CHKPT. 


SENDING CONTROL MESSAGES 


Control messages of the format "><CTLCKPnn"' are used to head data flow. 


During a session, one or several files can be transmitted, each file being termi- 
nated with an EGI. 


To allow for recovery, the pore application takes sindieneines at Suitable and 
regular intervals, and checks that the value of MODE is zero in order to continue 
with normal transmission. 


The checkpoint is then sent as a control message to esa the next stream of data 
flow. . | 


When the checkpoint and the accompanying data stream are completely received with 
out error, the system will release the disk space related to all the messages 
sent since the last valid checkpoint. 


The maximum number of disk blocks which can be retained between 2 checkpoints on. 
emission is given by the algorithm, 


(QDBLKSZ - 4) 


2 


where QDBLKSZ is the size of the disk block in bytes, dectered in the 
GENCOM command at CNC generation 
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SENDING CONTROL MESSAGES (continued) 
For transparent mode, the sender application must only take a checkpoint at the 
Start of transmitting a file and not during transmission. 


In this case, "><U06" must head the stream of data flow, see BSC2780 line proce- 
dure, page 5-13. 


RESTARTING AFTER A STEP ABORT OR SYSTEM CRASH 


The "restart" control message can be emitted from one of two sources, 
e either from the sender application in the case of a step abort 
e or from the system, in the case of a syStem crash for remote communications. 


The "restart" control message serves to warn the receiver application that all 
mesSages sent since the last valid checkpoint will be re-transmitted. 


The receiver application must therefore be programmed to nvers the duplication of 
messageSe 


If at the time of system reStart, the sender application is also to be restarted, 
then the receiver application will see two restart phases in the following se- 
quence, 


« firstly, it will receive the "restart" control meSsage from the system 


o then, it will receive the "restart" control message from the sender applica- 
tion. 


RESTARTING AFTER A LINE FAILURE 


A line is closed by the system if failure occurs 
e either due to a malfunction in the link-up 
e or at the receiver site, for whatever reason 


When the failure has been rectified, the line can be re-opened by the network 
control command RT LNnn, where nn specifies the line. 


The effects of this command on a BSC line are, 
e the line will be reactivated so | 
e the control message "><CTLRSTnn"' (ETB) will be sent 


e the terminal -queue will be restarted from the last valid ener indicated 
by nn of the "restart" control message. 


Transmission will resume on successful emission of the "restart" control message. 


Operator intervention at both sender and receiver sites may be required. 
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» Schematic Example | 
a | of 
“Sending "><CTL¢KPnn" Control Messages 


DATA DIVISION « | 


O1 MESSAGE . 
QO2 MES1 PIC x(8) « 
VALUE '"><CTLCKP" . 
02 MES2 PIC XXe 


COMMUNICATI ON SECTION. 


CD CD-OUT OUTPUT : | 
only user-initialized CD-output parameters are shown 
DESTINATION COUNT COUNT-OUT 

TEXT LENGTH ; LENGTH-OUT 

_ DESTINATION ~ DESTINATION-OUT « 

_ PROCEDURE DIVISION. 

MOVE. 1 TO COUNT-OUT. 

MOVE 10 TO LENGTH-OUT. 

_- MOVE destination TO DESTINATION- OUT . 

dynamic updating of current checkpoint nn by the user 


MOVE nn TO MES2. 2 
SEND CD-OUT FROM MESSAGE WITH {EME|ECT{ + 


$H_CD OUTPUT , PREFIX='USER_' ; 

only user-initialized CD-output parameters are shown 
USER_DESTINATION_COUNT = 1; 

USER_TEXT_LENGTH=10; 

USER_QUEUE_NAME = "destination" 5 


DCL MESSAGE CHAR(10) INIT("><CTLCKPOO") ; 
dynamic updating of current checkpoint nn by the user 


SUBSTR (MESSAGE 9,2) =nn; 


$H_SEND 'ADDR(USER_OUTPUT_CD) ' , INADDR= 'ADDR(MESSAGE)' , 
_ ENDCHAR = EMI ; | | 


$H_SEND 'ADDR(USER_OUTPUT_CD)' , INADDR= 'ADDR(MESSAGE)' , 
ENDCHAR = EGT ; ; 
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Example 
of 
Taking Checkpoints 


DATA DIVISION. 
O01 MODE COMP-2. - 
01 CKINF PIC X(32). 
PROCEDURE DIVISION. 
CALL “H_CK UCHKPT" USING MODE CKINF 


DCL VARIABLE1 FIXED BIN(31) ; 
DCL VARIABLE2 CHAR(32) ; 
$H_CHKPT MODE=VARIABLE1 , CKINF = VARIABLE2 ; 


Example 
of 
Setting STATUS 


DATA DIVISION. 
01 STATUS COMP-1. 


PROCEDURE DIVISION. 


MOVE 10000 TO STATUS. 
CALL "H_CBL_USETST" USING STATUS. 


| use 
leither form 


DCL STATUS FIXED BIN(15) ; 
_ STATUS = 10000 ; | 
$H_SETST STATUS ; 


9239 


application 


application 


restart from 


checkpoint , 


+1 


Recovery 
on the | 
Emission Side | 


Sender Application Absent 


Situation at Failure 


"S><CTLCKP. ,,"' — &><CTLCKP, "' 
i+ | 7 


‘ current 1st message after 


end-of-queue head-of -queue 1"! ><CTLCKP ia 


Situation at Restart 


current restart message 
head-of-queue heads transmission 


Situation at Failure 


1 ><CTLCKP.. 5 " " "| "! 


SEND 


last massage current lst message after 


in queue head-of -queue "><CTLCKP, _," 


Situation at Restart 


Bi 


SEND 
: restart restart message 
message - head-of-queue heads transmission 
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Recovery on the Reception Side 


Recovery of transmission on the reception side involves, 
« taking checkpoints | 
e receiving "'restart'' control messages 


e restarting the application 


TAKING CHECKPOINTS 
Whenever the receiver application receives the control message "><CTLCKPnn"' from 
the sender application, it takes its own checkpoint. 


The checkpoint taken by the receiver application has the same sequence number as 
the checkpoint from the sender application that triggered it. 


No control message is generated by the receiver application, instead, the check- 
point serves only as a recovery marke 


RECEIVING "RESTART" CONTROL MESSAGES 
"Restart"! is indicated by the control message "><CTLRSTii" sent by the sender 
application to the receiver application. 


The receiver application, in order to determine whether "restart" is possible or _ 
“not, will perform the following decisions on the sequence number "ii'' of the "'re- - 
Start'' control message, namely, 


» if ii#nn, where nn is the sequence number of the last checkpoint taken by 
the receiver application, then the control message "><CTLCKPnn+1" must have 
been lost along with its accompanying messages in the stream of data flow. 


~ In this case, no recovery is possible, and transmission must be reinitiated 
from the very beginning. 


e if ii=nn, then the receiver application must reSume from its current check- 
pointe 


To do this, the application must proceed as follows, 
- in MCS COBOL, by the program coding, 


e issuing a call to the H_CBL_USETST run-time package to set the STATUS 
register to an abnormally high value, say 10,000 


.e issuing a STOP RUN to return control immediately to the system 
- in GPL, by the program coding, 


e issuing a H_SETST system primitive to set the STATUS register to an 
abnormally high value, say 10,000 


» issuing a RETURN to return control immediately to the system 


The receiver application will terminate abnormally, and the system operator 
will then have to restart the application. 
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RESTARTING THE APPLICATION 
When it has been eceeitaga that Nrestart" is Soeibie, then pike receiver appli- 7 
cation is restarted from its previous checkpoint. | 
"Restart" does not. affect the sender application. 


The following events take al on ‘system restart after a step abort or system 
crash, namely, | | 


ie the system will reset the receiver application and its praawanenaeues to 
their previous checkpoint state 


° the terminal -queue related to the BSC link is empty 


e the line is reactivated by the network control command RT LNnn, where nn spe- 
cifies the line. : | : 


| Operator intervention at both sites may be required to reactivate the ite 
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EXECUTING MCS APPLICATIONS 


Preparing and executing communications applications involve 
« preallocating a disk‘ queue file 
e linking MCS applications 
e executing the communications step 


e Optimizing MCS applications. 


Preallocating a Disk Queue File 


If queves are to be held on disk, a file must be preallocated on a disk. Unless | 
otherwise stated in the QUEUE command at CNC generation, disk queueing is the de- 
fault option 


Preallocating a disk file is performed 
» by using the file level utility PREALLOC 


o before the CNC utility is executed, since the disk queue file must be prefor- 
matted aS a result of the network generation. 


If the file is to be modified, for example, altering the file size, the following 
procedure is performed in the sequence shown, 


» the file is deallocated by 

- either using the file level utility DEALLOC 

- or declaring MAM=NO at system initialization 
» the file is then preallocated through PREALLOC 


« the CNC utility is then executed to update the system tables with the new 
file information. — 


The disk file cannot be deallocated 
» if it is already defined for a network currently in use 


© if MAM=YES or MAM=REFORMAT was declared at system initialization, thereby 
- allocating the file to a system process group. 


The file level utilities PREALLOC and DEALLOC are to be found in the Data Man- 
agement Utilities manual. 


Preal locating a Disk Queue File 


$JOB ALLOCDQ USER=UNAME PROJECT =WAGE ; 


PREALLOC DQUEUE EXPDATE=365 DEVCLASS=MS/M452 _ 
GLOBAL = (MEDIA=VOL1 SIZE=5) | 
_ BFAS = (SEQ= (BLKSIZE=500 RECSIZE =500)) ; 


$ENDJOB ; 


Syntax concerning the parameters in the file level utility PREALLOC : 


the external- file- -name DQUEUE must be specified in a oe 
Statement at CNC execution 


the size of the file specified in cu example as 5 eylindees: is 
subject to the limits of the device class, see Network Generation | 
manual ; 


a disk queue file must bees a ateaeavaiuins file sa which the 
Starting cylinder cannot be specified, hence GLOBAL must be used 


the parameter group BFAS = (SEQ = (BLKSIZE = 500 RECSIZE = 500)) 
must be specified as indicated. 


the values of BLKSIZE and RECSIZE will be sveetiaden by CNC with 
values specified for QDBLKSZ in the GENCOM command. 
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Linking MCS. Applications 


An MCS application is compiled as follows, 
e in MCS COBOL, by the $COBOL statement, see COBOL User Guide 
e in GPL, by the $MACPROC and $GPL statements, see GPL User Guide. 


The compile units, cu's, of the MCS application are then linked by the LINKER 
Statement to form communications load-modules. 


In "Outline of JCL Statements for Linking. an MCS Application", the syntax for the 
JCL is as follows, 


© $LIB statement (for details of parameters, see Library Maintenance Ref. Man. ) 


- specifies the system library SYS.HCULIB containing the MAM run-time pack- 
age 


- specifies the libraries containing the user cu's to be linked 
- describes the search path to the Static Linker. 
« $LINKER statement (for details of parameters, see Linker manual) 
- OUTLIB specifies the library in which the load-module is to be stored. 


If the argument TEMP is chosen, then linking and load-module execution 
takes place within the same job. 


= parameters applicable to a monoprocess load-module : 
© ENTRY specifies the entry point to the application. 
The default entry point is the name of the load-module. 
« COMFAC identifies the application as a monoprocess load-module. 
- parameters applicable to a multiprocess load-module ; 


e COMFILE names the input enclosure required to link a multiprocess 
load-module. 


-» input enclosure statements ; 


The information given applies in the case where the system procedure 
| STUSERS is used. 


An MCS application written in GPL has the choice of either using the system 
procedure STUSERS or a user-defined ENTRY procedure, see "Example of user- 
defined ENTRY Procedure", page 2-49 


- ENTRY and LINKTYPE must be entered exact ly as indicated with the parame- 
ters given 


- TASK statement ; 


e USERn is used by MCS. to-start the indicated task in the order from 
USER1 through USER6, where appropriate 


« START =STUSERn indicates the entry point of the associated task USERn 
- REPLACE statement ; 


« Cu-namen is the entry point in the application to be linked to the 
task USERn 


e CU=STUSERn indicates the compile-unit of the associated task USERn. 
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Out line of ICL Statements 


for 
- ‘Linking, an ‘MCS Application | 


$JOB job-name USER iaiaagea PROJECT = project-name ; 
4 eo SYS. HCULIB — - 
LIB CU INLIBi= 4 TEMP — 
| (simple-file-deseription) 


TEMP | 


INLIB2 = ‘ (simple-file-description) 


{TEMP 
-— [swras{ (simple- -file-description) | 


LINKER load-module-name [ entry = =cu-name | 


TEMP 
ours» = { (simple-fi le-descrip tion) an 
{ COMFAC | ; 
| COMF ILE = *input-enclosure-name 


The following input enclosure is to link a multiprocess load-module 
where COMFILE is specified. 


The enclosure is bypassed where COMFAC is specified. 


$INPUT input-enclosure-name ; | 
ENTRY = STUSERS , 
LINKTYPE = BMAM , | 
TASK =(USER1 START =STUSER1) , 
REPLACE = (DUMMY cu-name1 CU=STUSER1) , 
TASK=(USER2 START =STUSER2) , | 
REPLACE = (DUMMY cu-name2 CU=STUSER2) , 


TASK=(USER6 START =STUSER6) , 
REPLACE = (DUMMY cu-name6 CU=STUSER6) , 
$ENDINPUT ; 


$ENDJOB ; 
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LINKING A MONOPROCESS MCS LOAD-MODULE 
In "Example of Licking a Monoprocess Load-Module", the syntax for the JCL is as 
follows, | 
» $LIB statement : 
_- UCULIB is the cu-library on volume VOL1 containing the user application. 
$LINKER statement : | 


- MAM1 is the name of the load-module and is also the entry point to the 
user application 


- ULMLIB is the user load-module library on the volume VOL1 in which the 
load-module is to be stored. 


LINKING A MULTIPROCESS MCS LOAD-MODULE 


Linking a multiprocess MCS load-module can be done © 
e either by using the system procedure STUSERS 


2 Or, in the case of a GPL, by creating a user-defined ENTRY procedure and us- 
ing it in place of STUSERS. 


° Using the System Procedure STUSERS : 
In "Example of Linking a Multiprocess Load-Module", the syntax for the JCL 
is as follows, | 
» $LIB Statement :; 


- UCULIB1 and UCULIB2 are the cu-libraries on the volume VOL1 con- 
taining the user application. 


» $LINKER statement : 


- ULMLIB is the user load-module library on the volume VOL1 in which 
the multiprocess load-module MAM2 is to be stored. 


e input enclosure statements (sequence of statements is not significant) 


- DATCOLL is an entry point to the user application which is to be 
linked to the task USER2 


- INQRESP is an entry point to the user application which is to be 
linked to the task USERI. 
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Examples 
of 
Linking MCS mppstcotsene 


Linking a 
_Monoprocess 
Load-Module 


$JOB LINK1 USER=UNAME PROJECT =ACCT ; 


LIB CU INLIB1=SYS. HCULIB 
INLIB2 = (UCULIB DEVCLASS=MS/M452 MEDIA=VOL1) ; 


LINKER MAM1 
OUTLIB=(ULMLIB DEVCLASS = us/Mos2 MEDIA = VOL1) 
COMFAC ; 


$ENDJOB ; 


' Linking a 
Multiprocess | 
Load-Module 


$JOB LINK2 USER =UNAME PROJ ECT = WAGE 3; 


LIB CU INLIB1=SYS. HCULIB 
INLIB2 = (UCULIB1 DEVCLASS = MS/M452 MEDIA = VOL1) 
‘INLIB3 = (UCULIB2 DEVCLASS = MS/M452 MEDIA =VOL2) ; 


LINKER MAM2 | 
OUTLIB = (ULMLIB DEVCLASS = =n /6452 MEDIA = VOL1) 
COMFILE = oer 


$INPUT LINK; 

ENTRY = STUSERS , 

LINKTYPE = BMAM , 

TASK =(USER1 START =STUSER1) ,_ 
TASK=(USER2 START =STUSER2) , 

REPLACE = (DUMMY DATCOLL CU=STUSER2) , 
REPLACE = (DUMMY INQRESP CU=STUSER1) , 
$ENDINPUT ; 

$ENDJOB ; 
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LINKING A MULTIPROCESS -LOAD-MODULE (continued) 
° Using a user-defined ENTRY Procedure : 
In GPL, the user has the choice of specifying and managing his own tasks and 
subtasks by the means of the H_BEGTSK and H_WAITSK primitives, whereby 
» the name of the procedure in the ENTRY command is user-defined 
e the names of the tasks in the TASK commands are user-defined 


« the entry points, however, invoked by the above primitives are referenced 
by STUSERn, n ranging from 1 through 6, such that 


- each STUSERn executes a "call'' to the user application through a user 
defined entry point specified at linkage time 


- each STUSERn invokes MCS to perform housekeeping functions before 
terminating the associated task. 


An additional advantage of the user-defined ENTRY procedure is that other 
tasks not containing MCS primitives can be included. 


MAIN 


1 $H_BEGTSK 


$H_WAITSK 


sruser1] ©/ [srusero| | STUSERG | 


i"call" call 


Q@ [RETURN\ | RETURN 


The secondary tasks identified by FIRSTTASK and SECONDTASK are user-defined 
and contain MCS primitives. 


1 $H_BEGTSK directive is issued to STUSERI1 

2 This results in a "'call" to the user-defined secondary task FIRSTTASK 
3 After FIRSTTASK is performed, control is returned to STUSER1 
4 


MAM is now invoked to perform housekeeping functions. 


3 ‘Reanpile of 
| user-defined ENTRY Procedure 
“(the | name of the user-defined pee is aoa, 


Example of Programming 
MAIN in GPL 


- MAIN: PROC ; 


DCL 1 STRUC1 woe ; 

DCL 12 STRUC2 eee 3 F 

up to 6 "tasks!" 
may be declared] 


$H_BECTSK NAME="FIRSTTASK" | OPTIONS =STRUC1 
$H_BEGTSK NAME="SECONDTASK" | OPTIONS =STRUC2 
$H_WAITSK NAME="FIRSTTASK" ;__ | a“ 
$H_WAITSK NAME ="SECONDTASK" ; 

RETURN ; 

END ; 


Linking Multiprocess Load-Module 
using MAIN 


$JOB LINK2 USER=UNAME PROJECT =WAGE; 


LIB CU INLIB1 = SYS. HCULIB 
-INLIB2 = (UCULIB1 DEVCLASS = MS/M452 MEDIA = VOL1) 
INLIB3 = (UCULIB2 DEVCLASS=MS/M452 MEDIA =VOL2) ; 


LINKER MAM2 OUTLIB= (ULMLIB DEVCLASS =MS/M452 MEDIA =VOL1) 
COMFILE = *LINK ; 


$INPUT LINK; 
ENTRY =MAIN , 
LINKTYPE=BMAM, 
TASK = (FIRSTTASK START =STUSER1) , 
TASK =(SECONDTASK START=STUSER2), 
REPLACE = (DUMMY DATCOLL CU=STUSER2) , 
REPLACE = (DUMMY iNQRESP CU=STUSER1) , 
$ENDINPUT ; 
$ENDJOB; 
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Format and Syntax 


of 
$QASSIGN Statement 


een symbolic-queue-name [. symbolic-subqueue, -name 


1 
[. symbolic-subqueue,-name 


[. symbolic-subqueue,-name ] ] ] 


ext ernal- queue, -name 
IN | { LIN ] : 
— ACCESS = 5, —— 
INOUT RR REPLY = external-queue,-name 
OUT 


SITE = systen-nane | : 


Description of Parameters 


external-queue-name | 
- ranges from 1 Recs 12 alphanumeric characters and is the name of the cor- 
responding QUEUE command at network generation 


symbolic-queue-name 
- identifies the logical queue defined as follows 
e in MCS COBOL, in data-name-1 of the CD area (input and output) 
e in GPL, by QUEUE NAME of H_CDOUT or H_CDIN. 


symbolic-subqueue-name 
- applicable only for input queues for partitioning the logical queue as follows 
o in MCS COBOL, in data-name-2, data-name-3 & data-name-4 of the input CD area 
e in GPL, by SUBQUEUE_NAME, SUBQUEUE2 NAME and SUBQUEUE3_ NAME. of H_CDIN. 


ACCESS | 
- applicable only to input queues if partitioned into subqueues, to specify how | 
the subqueves are to be scanned on "receive" as follows 
o LIN: "linear", the search starts at the first subqueue specified, default 
e RR : "round-robin", the search resumes at the subqueue immediately EQnTOeINS 
the subqueue that provided data on the last "receive" 
IN 
- "input mode", applicable only to program-queues, default. 
INOUT 
- "input/output mode", applicable only to program-queues and must not be speci- 
| fied for subqueues. 
| OUT | | 
| - “output mode", must not be specified for sub 
| REPLY 
- applicable only to "“application-to- application" communication and must not be 
specified with the IN "processing mode". . 7 


JUCUES. 


| SITE 
| - identifies a DSA system which can be either "Isys" or "rsys" being DPS 7's. 
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| ‘DEFINITION OF - $aassrcN 


The $QASSIGN statement | performs die following, 


, defines the symbolic quceues and, ‘where applicable, the subqueues to be used on — 


os input 


establishes the correspondence between the symbolic queue and its associated 


Subqueue(s), if the. queue is to»be.used for input, and the external ‘queue spec- 
ified in the QUEUE command at network generation 


identifies the "processing mode" of the queue with respect to "send's" and "re- 


ceive's!" 


allocates the queues to the job step. 


RULES FOR USING $QASSIGN 


The following rules govern the use of the $QASSIGN statement, 


the order of the list of subqueues within a symbolic input queue is determined 


by the order of $QASSIGN statements within the step enclosure 


the maximum number of $QASSIGN statements. permitted within the step enclosure 


is 26 


the ACCESS parameter is only relevant in the first $QASSIGN statement defining 
a queue Structure, that is, subqueues within the q queue 


a $QASSIGN statement pene enony for each input queue associated with the ap- 


plication 


$QASSIGN statements for output queues are optional 


REPLY defines another "“program- queue"! which is identified as the source of in- 
put messages in the destination application's input CD area (H_CDIN), such that 


the destination application can answer back, using in its turn, the "program- 
queue" thus defined as the "destination" 


on output queues where the REPLY option is not specified, an implicit REPLY 
(towards the first input queue among the $QASSIGN statements) is peovedee if 
any such queue exists 


where disk queues are used, no $ASSIGN statement is required because the file 
is opened at system level and is therefore sharable by all process groups. 
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Example of 
Run-time JCL 
with $QASSIGNs 


$JOB TELECOM USER=UNAME PROJECT=ACCT CLASS=H; 
STEP MAM3 (ULMLIB DEVCLASS=MS/M452 MEDIA=VOL1) ; 


defines INQ queue structure, b: defines terminal queues | 


QASSIGN INQ.SUB1 PRG1 ACCESS = RR 3 


QASSIGN INQ SUB2 PRG2; 
QASSIGN INQ. SUB3 PRG3; 
QASSIGN INQ. SUB4 PRG4; 
QASSIGN OUTQ TRM1 OUT; 
QASSIGN OUTW TRM2 OUT; 


ENDSTEP ; 
$SENDIJOB 3 


EXAMPLE OF RUN-TIME JCL WITH $QASSIGNS 
In "Example of Run-time JCL with $QASSIGNs", the syntax of the statements is as 
follows, 

e $JOB statement :. 


- CLASS=H is recommended for a communications step to ensure adequate res- 
ponse time in a multiprogramming environment 


$STEP Statement ;: 


- MAM3 is the multiprocess load-module linked and stored in a previous ses~ 
sion in the user load-module library ULMLIB 


eo $QASSIGN statement : 


- group a , each symbolic-subqueue corresponds to a unique external-queue- 
name, that is, SUBn maps on to PRGn, specified in the associated 
QUEUE commands at CNC generation, and will be penne in "“round- 
robin" in the. order specified 


= group b , the symbolic-output-queues OUTQ and OUTW are associated with 
their respective terminal-queues TRM1 and TRM2. 


2-53 


ee, ic bana Cioae: for apcleies MCS apeties tens involve the use of the 
"timer"! which is set accordingly as follows, 


in MCS COBOL, by the statement CALL to the run-time package H! ™ _USETTM 


in GPL, by the system primitive $H_SETELT. | 


“timer"' is set under the following conditions, 
when issuing a RECEIVE (H_RECEIVE) with "no data" 
when issuing an ACCEPT (H_MSGCNT) 


when handling several program-queues. 


ISSUING RECEIVE (H_RECEIVE) 


The 


° 


° 


2 conditions for issuing a RECEIVE (H RECEIVE) are, 
when not qualified by a "no data" clause 


when specified with a "no data" clause. | 


Not Qualified by a "No Data" Clause " 


One of the following 2 conditions will occur, 


- if at least 1 message is queued, then it will be delivered into the user- 
specified working area, before control is given back to the ap pEecaeecy 
to determine what next to do 


» if the queue is empty, MCS suspends the Sppr Teeter until a message ar- 
rives in the queue, 


When a message arrives, it is delivered into the user-specified working 
area, and control is again returned to the application. 


Specified with a "No Data" Clause : 
RECEIVE (H_RECEIVE) with "no data" is used to scan a queue while executing 
another process or while awaiting the occurrence of other events. 


If a message is available in the queue, the "no data" condition is bypassed 
and the resulting action is the same as for a RECEIVE (H_RECEIVE). 


If no message is available in the queue, the "no data'' condition is entered 
and the application will loop on this condition until a message arrives, 
thereby causing the application 


e to occupy all the CPU time not used by BINS, FNPS or GCOS | 
e« to ‘prevent the execution of any batch program 
» to reduce the throughput of the system 


In order to avoid the degradation in system performance, Setting the "timer" 
in the "no data" loop allows the application to be i for a user- 
specified time Oebone being re-activated. | 
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Schematic Example 


| of 
RECEIVE with 'no data! 


DATA DIVISION. 
O01 BUFFER PIC X(nn). 


COMMUNICATION SECTION. 
CD CD-IN INPUT 
TEXT LENGTH LENGTH-IN 


PROCEDURE DIVISION. 
MOVE nn TO LENGTH-IN. 
REGV « 
RECEIVE CD-IN MESSAGE INTO BUFFER NO DATA GO TO SETTIMER. 
SETTIMER » 
set timer 
GO TO RECV. 


MCS 
|COBOL 


$H_CD INPUT PREFIX='FIRST '; 
DCL BUFFER CHAR(nn) ; 

RECV : 3 | | | 
$H_RECEIVE "ADDR(FIRST_INPUT_CD) ' , OUTADDR= 'ADDR( BUFFER)! , | 
ee LENGTH = nn , NWAIT ; i ne: (ie 

IF $H_TESTRC EMPTY; THEN GO TO SETTIMER; 


SETTIMER 3: 3 
set timer 
GO TO RECV; 


Example of 
Setting Timer 
(nn is specified in milliseconds) 


DATA DIVISION. 
O1 DELAY-TIME COMP-2. 


PROCEDURE DIVISION. 
MOVE nn TO DELAY-TIME. 
CALL "H TM USETTM'" USING DELAY-TIME. 


DCL DELAY_TIME FIXED BIN(31) ; 


DELAY TIME = nn ; | 
$H_SETELT MILSEC = DELAY T IME 3 
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ISSUING ACCEPT (H_MSGCNT) — 
_ ACCEPT (H_MSGCNT) is used to ascertain the number of messages in a queue while 
executing another process or while awaiting the occurrence of other events. 


If the message count is not zero, that is, there is at least 1 message in-the | 
queue, the application will continue normal processing. — 


If the message count is zero, the application will loop on this condition until 
a message arrives in the queue to update the message count to MONA ZEEO, thereby 
causing the application 


« to occupy all the CPU time not used by BINS, FNPS or GCOS 
e to prevent the execution of any batch program 
. to reduce the throughput of the system. 


In order to avoid the degradation in system performance, setting the "timer" in 
the "message count =zero'' loop allows the application to be suspended for a uSer- 
specified time before being re-activated. , 
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Example of 
Setting Timer with 
ACCEPT (H_MSGCNT) 


DATA DIVISION. 
O1 DELAY-TIME COMP-2. 


COMMUNICATION SECTION. 
CD CD-IN INPUT 
MESSAGE COUNT 


PROCEDURE DIVISION. 
ACCPT . 


ACCEPT CD-IN MESSAGE COUNT. 
IF MSG-CNT=0O GO TO SETTIMER. 


SETTIMER « © 


MOVE nn TO DELAY-TIME. 
CALL "H_TM USETTM" USING DELAY-TIME. 


GO TO ACCPT. 


$H_CD INPUT PREFIX='FIRST_' 3 
DCL DELAY TIME FIXED BIN(31) ; 


ACCPT ; 3 
$H_MSGCNT '‘ADDR(FIRST_INPUT_CD)'° ; 


IF FIRST_MSG CNT=0 THEN .GO TO SETTIMER; 


SETTIMER : 3 
DELAY_TIME =nn ; | 
$H SETELT MILSEC=DELAY TIME ; 
.. GO TO ACCPT ; 
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HANDLING SEVERAL PROGRAM-QUEUES 


As a sane cu! rule, most. aoe ieneoeass handle only 1 program-queue which is the 
-“point-of-entry" for all data received. | | ‘ 


In some cases, the application. may. have to handle several program-queues under 


| the following conditions, 


« an order of priority is to be sdtabivenca between more than 1 source of mes- 
_ Sages so that 1 particular source can be selected at a given time 


- the application is to communicate with a comp lex of eeeminene and with eith- 
er or both | 


- a process of che same application 


-~- another application. 


Problem : How to scan 3 jvopren=cucues Q1, Q2 and Q3 in which an applica- 


tion is to receive meSSages. 


Solution 1 ; Each of the 3 queues is defined by a separate sQASsIGN een eeuratas 
7 whereby each is unrelated to the others. 


The application can then establish the order of peieeie in which 
the queues are to be scanned, say, Ql having the lowest priority and 
Q3, the highest, by performing the following, | 


_« looping on RECEIVE (H_RECEIVE) with "no data" successively for 
each queue starting with Q3, since Q3 has the highest priority | 


e setting the "timer" in the "no data" loop to suspend the appli- 
cation until a message eventually egeeues available in the queue 
concerned. 


The drawbacks of this solution are, 

- by establishing priority among the queues, the application is 
unnecessarily suspended if, say, Q3 which has the highest prior- 
ity is empty, and pending the arrival of a message in Q3, the 
other queues Q1 and Q2 are left unscanned. 

This unnecessary suspension can be avoided if all the queues are 
scanned and if no message is present in any of the queues, to | 
set the "timer" before rescanning the queues. | 

. the "timer'' is arbitrarily set and therefore is difficult to 
optimize, giving rise to the following situations, 


- if the "wait-time" is too large, the "turn-around" time for 
processing becomes too slow 


- if the 'wait-time" is too small, the application will loop 
on itself until a message becomes available in the queue 
concerned, thereby defeating the purpose of the "timer". 
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Solution 2 : Each of the 3 queues can be defined as subqueues of the queue, say, 
QIN, such that the $QASSIGN statements for the 3 queves represent 
an interrelated hierarchy, as shown in the diagram following, 


subqueue 
Qi 


subqueue 
Q2 


Subqueue 
Q3 


In this case, the application has only to issue a RECEIVE | 
(H_RECEIVE) not qualified by a "no data" clause to the queue QIN, 
without having to specify the individual subqueves Qi, Q2 and Q3. 


As will be seen later on, the priority to be given to the sSubqueue 
is resolved when the "received" message is to be processed. 


The advantages of this solution are, 


e from the point of view of the scanning mechanism, the 3 queues 
Qi, Q2 and Q3 represent a single queue, QIN, and the likeli- 
hood for all 3 subqueves to be empty at the same time is small 
and therefore there is no need to specify the "no data" condi-~ 
tion 


e if no message is available in any of the 3 subqueues, MAM will 
Suspend the application, and processing will resume only as 
soon aS a mesSage arrives in any of the subqueues. 


» the RECEIVE (H_RECEIVE) will indicate in the input CD (H_CD) 
from which subqueue the message has been "received'"'. 
The application can then place whatever priority it wants on 
processing the message. In this case, for consistency, the 
messages from subqueue Q3 will be processed first, even if 
there are other messages preceding it from the subqueues Qi 
and Q2. 


The method of scanning the queues is dealt with in the description 
of the ACCESS parameter of the $QASSIGN statement on page 2-51. 
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SECTION III 


MCS DATA FORMATS 


This section deals with the format of data sent to and received from a terminal 
by an MCS application. 


The data is held in the working area defined as the uSer buffer and accessed by 
the SEND (H_SEND) and RECEIVE (H_RECEIVE) communications verbs. 
Data comprises, 
« graphic symbols, which are, 
- numeric characters 
~ alphabetic characters, both upper and lower case 


- special characters, such aS, punctuation, mathematical and currency 
symbols 


e control codes, which provide terminal management functions, such as, 


- editing or service functions, for example, carriage-return, tabulation 
and cursor positioning 


- auxiliary device commands, such as, to the cassette handler 


~ timing functions, such as, "time-fill's" to allow for slow mechanical 
functions on a printer 


- mesSage delimiters, such as, VIP headers, "end-of-transmission-block", 
and trailers. 
This section is dealt with in terms of, 
e Symbolic representation 
» transmission modes 
e MCS data processing 


e data representation 
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SYMBOLIC REPRESENTATION 


On keyboards where the graphic symbol or control code is present, pressing the 
respective key results in the transmission of a 1-byte hexadecimal value from _ 
the terminal to the user buffer. 


However, not all terminals are aquipped with the set of graphic ee and 
control codes as shown in the "ASCII" and "EBCDIC" tables. 


In the absence of such graphic symbols and control codes, another means must be 
found to represent these, namely, by using the graphic symbols >< to denote 


- the character-encoding mark ><Cxy, where xy represents 2 hexadecimal- 
digits corresponding to the EBCDIC verus of the graphic symbol or: control 
code | | | 


. the mark Pccn-veneesaheucton ><ccc, where ccc represents dhe 3- character 
mnemonic of the control code, see "Control Codes" 


« the repeat mark ><Rab, where ab represents 2 decimal-digits, being the 
number of times the graphic symbol, and in some cases, the control code, is 
to be repeated 


- the VIP header of the Bora ><u03 Dene pe are the "status" and “function- 
—  code's", | | 


This symbolic vepteweneacion of deta is a feature provided by MCS at user pro- 
gram revels | | 
In the "ASCII" table, values greater than hexadecimal 80, are not Peunpes one 
either by control codes or graphic symbols. | 


These "unreserved" codes can therefore only be symbolically represented, and 
when specified in unedited mode, both on input and output, can be used for spe- 
cific user-defined functions. 
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____ CONTROL CODES 


List of Common Control Codes 


(for specific control codes, see Section VI"'Programming Terminals") 


| 7 _ |EBCDIC ae | 
Beeceea ads | ASCII COBOL denotes "collating sequence" 
; | COBOL abbreviated to COBOL C/S in tables | 
| | EBCDIC 
acknowledge | 06/47@ control code ASCII 


advance 1 page OC 


= FFV ETB end of transmission 


advance i line block 


= CRV LFV ETX end of text 


bell 07] 
for VIP terminals, BEL : 
generates BLK 


IFFY form feed 
| = BOl 


. FSV file separator 
blink 5E 
7 | mGSV group separator 

backspace | O8 | 
| P| HTV horizontal tabulation 

cancel | 118; 18 
SLFV line feed 
carriage return OD | 
| negative acknowledge 


device control 1 11] 
| new line (BSC3270) 


device control 2 ! 12 : = CRV LFV 


for VIP terminals, DC2 


null 
generates forward space | 


record separator 


device control 3 13 


device control 4 : 14 shift in 


sia 7F | shift one 


data link escape | 10| Start of header 


EMV end of medium | 7 19] Start of text 


: eee eee bstitut 
1ENQ enquiry | 1D} O05] Pe ney ae 


| EOT end of transmission | 04 | synchronous idie | 


ESC escape — - (27/13 7USV unit separator 


: SVIV vertical tabulation 
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_ Where a touch-key representing a control code is absent on the keyboard, the on- — 
ly means of entering the Sonrees code is using its mnemonic form preceded by the 
symbols ><. | | | | 


Using the table "Control Codes", which ieee the comuiiin coace ee by their 
mnemonic form to the "stream processor", the sequence ><ESC can be keyed in, if 
for Sa a the touch- sney representing ESC is not pEeeoue on the Bey ECaeCs | 


On output, however, control codes are treated according to their applicability 
to the line procedure, namely, in the output normal mode, 


- those codes applicable on output are translated into 1-byte hexadecimal val- 
ues 7 | 


e non-applicable codes pass unchanged in their original mark form. 


The following control codes in mark form pass unchanged to the terminal in out- 
‘put normal mode, and are deleted if preceded by the "repeat" function. 
| line procedure 7 control codes not applicable on output 
BSC2780 ACK ><ENQ ><RSV ss ><SOH~=—s—s«éO SYN 
BSC3270 | ,  ><ETB ss SIV KSTX sé CSV 


vip sy <D - ><NAK ss ><SOV >< SUB ><vIV 


Character-Encoded Form 


Character-encoding is used to enter 2 hexadecimal-digits preceded by the mark 
><C, and is a means of representing such data as, 


» control codes for which no touch-key representing their function exists on 
the keyboard 


« graphic symbols which have no sieviavebie equivalents on the submitter ter- 
minal but which can be displayed on the receiver terminal, see "Processing 
on Output". 


In input normal and marked modes, the character-encoded mark ><C passes the 
following 2 hexadecimal-digits as a 1-byte hexadecimal value to the user buffer. 


In output normal mode, character-encoding is used to represent control codes 
not applicable for output for the line procedure concerned, see the individual 
tables for the different line procedures under "Output Normal Mode''. 


The non-applicable control code, is treated like a non-displayable graphic sym- 
bol, and is translated from its 1-byte hexadecimal value into character-encoded 
form and transmitted to the terminal. 


TRANSMISSION MODES 


Except for BSC2780-like terminals, the transmission from a terminal to the Level 
64 is in ASCII code. 


The translation of the ASCII code to EBCDIC code, which is the internal code of 
the DPS 7, is performed by means of the TCT, by either the URP or by the DN7100, 
depending on whether BINS or FNPS is involved. 

BSG2780-like terminals transmit in EBCDIC code, so further translation is not 
required. 


The EBCDIC code is interpreted by the "Stream processor" of QMON for the type of 
conversion according to the transmission mode specified by the user. 


The data, having been suitable treated, then passes to the user buffer for pro- 
cessing by the MCS application. 


On output, the process in reverse operates. Transmissions to the terminal which 
correspond to neither a displayable graphic symbol nor to a valid control code, 
result in temporizing "time-fill's"', : 
The mechanism of the "time-fill" is a useful feature when programming for non- 
Standard terminals. 


The transmission mode can be declared at network generation and dynamically 
changed during the course of the communications session 


For both input and output, normal and unedited transmission modes are available. 
However, for input, an additional transmission mode, the marked mode is avail- 
able. 

In the following examples of transmission modes, the conventions used are, 


_indicates a i-byte EBCDIC hexadecimal value 


value activated by the "carriage-return' control key 


ory| indicates the transmission of a control code as a 1-byte hexadecimal 

>| indicates. the transmission of a graphic symbol as a 1-byte hexadeci- 
mal value activated by a touch-key, in this case, ''D"' 

indicates the 1-byte EBCDIC hexadecimal value and is used to show 

the conversion from/to 2 hexadecimal-digits preceded by ><C 


D | 


indicates any data not affected by the "stream processor"! 


indicates the direction of ee peace from the terminal to the 
user buffer or vice versa 


indicates the string-grouping of characters as processed by the 
"Stream processor" 


For the normal output transmission mode, certain control codes and graphic sym- 
bols do not apply for specific line procedures. | 
"OQutput Normal Mode" tables are provided for each line procedure supported. 


For input, the table "Input Marked Mode" treats all the common control codes ine 


mark form and passes all other data unchanged to the Level 64 
In the input normal, single control codes, except for HTV_ and ESC, are deleted. 
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denotes that no control code 
or graphic symbol is present 


CCBOL C/S COBCL C/S denotes "collating sequence", 
jCode:S mbol obtained from the decimal conversion of 
ASCII the EBCDIC hexadecimal vaiue, then add 1 


133} d 

134] e COBOL C/S 

135] £ Code: Symbol 

136] g 

137} h @ 90 

138] i 991 [coBoL C/S 

146] 3 92 Code: Symbol 

147} k 493 ASCII 

148} 1 94 EBCDIC . 

1491 m 995} COBOL C/S 

150} n 996] Code: Symbol 
151} o 997 a , 


152} p 898 
153} q #99 
154] r 9A 
163] s 9B 


Jewns mene xX geen 
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EBCDIC 


f EBCDIC 
ASCII | : 
COBOL C/S o 
Gode: Symbol 
= EBCDIC 
1{NULG ASCII 
2|SOH & COBOL C/S 
02/02] 3|STX§ Code: Symbol 
: # EBCDIC 
* ASCII 
COBOL c/s COBOL C/S denotes "collating sequence", 
Code:S mbol obtzined from the decimzl conversion of 
EBCDIC the EBCDIC hexadecim2l vziue, then add 1 


denotes that no control code 
cr graphic symbol is present 


COBOL C/S 
Code: Symbol 


! EBCDIC 


COBOL C/S 

Code: Symbol 
| EBCDIC 
ASCII 
COBOL C/S 
Code: Symbol 


Hrany moow pe 


oOo SIaOU LW eH O 


ODO wo“zksern or 
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- MCS DATA PROCESSING 


On output, the characteristics of the line procedure are important, since cer- | 
tain control codes and, in some cases, graphic symbols, are not applicable, see 
the tables of individual line procedures under "Output Normal Mode". | 


For this reason the table "MCS Data Processing" is based on the BSC2780/VIP line 
procedure. The principles that govern the handling of data formats on output for 
the Ereeeeryaye line PRecOtures must be eppstes according ly to other line proce- 
dures. 


The EBCDIC values chosen for iene MCS dave pecesusine are, 


e "Oct corresponding to ene control code FFV which is valid for all line pre 
cedures : 


« "32" corresponding to the control code SYN which does not apply in output 
_ mode for the BSC2780/VIP line procedure 


« "G7" corresponding to the letter G which is a bEyPESae example of a display- 
able graphic symbol 


. "FD" having no equivalent either as a control code or a seuehic symbol in 
any line procedure. 
The points to be noted in the table, are 


» Control codes in mark form, which are applicable to the line procedure, are _ 
translated as 1-byte hexadecimal values on output 


« Control codes in mark form, which are not applicable to the line procedure, 
pass unchanged on output, and are deleted if preceded by "'repeat" | 
» Character-encoded hexadecimal values are processed in exactly the same man- 


ner, irrespective of the fact whether these values PeErespons: to control 
codes, graphic symbols or to neither 3 


« i-byte hexadecimal values on input are handled accordingly as follows, 


- if representing control codes, are processed in exactly the same manner, 
with the notable exceptions of HTV and ESC which in normal mode pass un- 
changed as "05" and "27" respectively 


- otherwise, they are processed regardless as graphic symbols 


» 1-byte hexadecimal values on output are handled differently in normal mode, 
where no "repeat'' precedes the value, namely, 
- if representing control codes, applicable to the line procedure, or if. 
corresponding to a displayable graphic symbol, are. passed unchanged 


- otherwise, they are translated into character-encoded hexadecimal val- 
ues. 


The 1-byte hexadecimal value is generated by the activation by a touch-key, re- 
presented either as a control code or graphic symbol on the keyboard. For this 
reason the value "FD" shown in the table in input mode is only meaningful when 
considered as a non-standard code, for example, for national keyboard options. 


VIP headers and trailers are dealt with in detail under each of the process 
modes. | 
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MCS Data Processing 


(based on BSC2780/VIP line procedure) 


Data from || INPUT | OUTPUT 
Terminal or | | - J | | | 
in Buffer Normal Marked Unedited Normal Unedited 


><FFV _ ><FFV >< FFV noc 
delete delete >< R02 >< FFV "OCOC!! 


><SYN 


><syN | ><SYN 


delete delete delete 


"moc 
"ococ" 


><coc || 
><RO2><coc| | 


nog 
UL @[ @ @ | Ga 


Nog? 
NOCOC!! 


><RO2 ><COC 


>< R02 ><COC 


><032 
| >< RO2><C32 


><C32 


te WAL : 
| >< RO2 ><C32 


"3232" 


><C32 
1 ><RO2><C32! | 


"m3 2" 
93939" 


ic Ae 
"3.232" 


><CC7 
| ><RO2 ><CC7 


><CC7 
>< R02 ><cC7] | 


ey i 
"C7C7" 


Ul @ay Al 
"C7G7" 


><cc7 


| | nc 
><R02 ><cC7} | 


"NcCT7C7tt 


| ><cFD 
| ><RO2 ><CFD 


EH 
'MEDFD " 


Rpt 
NEDFD"'! 


><CFD 


| EH tH 
><RO2 ><CFD] | 


WEDFD v8 


| ><Ro2><cFD| | 


delete 


“oc | not HTV/Esc|  ><FFV noc noc "och | 
><RO2"0Cc" |] "ococ" "ococ" >< RO2"0C" "ococ" >< RO2"0C" 


><C32 "32" 


delete 
"3232" ><R02"32" | 


"3232" 


Ngo 
>< R023 2" 


><syn | 32" 
"3232" =| ><RO2"32" 


| UL Oy AL 
"C7G7" 


ow Al | | UT Oy A . 
"C7C7" ><RO2"C7" | 


mc 7" 


[| 7 Nov 
><RO2"C7" || 


Nnoq7" 
Ne7C7" 


><Ro2"c7" | | 


wep! >< CFD Weep 


WED | 
><RO2"FD" “pDFD" = | ><RO2NED" | 


: WEDFD" 


NED 
— ><Ro2"Ep" || 
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| 7 Processing on. Input — 
The 3 transmission modes for processing on input are, 
- input marked mode 
-. input normal ‘mode. 
e input unedited mode. 
The table "Input Marked Mode" is applicable for all line eeccstarae, and gives 


the i ea list of control codes known to the "stream processor" in their mark 
form. 


These control codes in mark form, when appearing singly, pass unchanged to the 
user buffer in all the 3 aepoe Berne 


The 2 control code exceptions in teen. normal mode are HTV and ESC, which unlike 
the other control codes, are not deleted from the user buffer. : 


All other values, which are not control codes, are treated as gekphtc symbols, 
whether or not a displayable symbol exists, and pass unchanged, when appearing 
Singly, to the user buffer. 


The input ssdasaees mode passes all dses unprocessed to the user buffer, and all 
verification of data must be performed by the MCS application. 


INPUT MARKED MODE 


Gods: Symbol ___— ALL LINE PROCEDURES | 


Character String 


1EBCDIC Value 

Code : Symbol 

EBCDIC Value or 
Character String 


EBCDIC Value 
Code : Symbol 
EBCDIC Value or 
Character String 


J EBCDIC Value 


denotes that no ccntrol code 
or graphic symbol is present 


64 ff Ccce : Symbol 
65 , EBCDIC Value or 
66 Charecter String 
¢ ae m EBCDIC Value 
B3C ><DC4E 6& Code : Symbol | 
B 3D | NAK| >< NAK @ 69 EBCDIC Value or 
S3E Gee 835 6A Character String 
pSF SUB SSue es oF B8s [BP ESCDIC Valve 
B40/ 9 : 6C Code : Symbol _ 
see tee | 6D EBCDIC Value or |. 
6E Character Stringe 
OF 897) p | 97 E_ieeees lL. lCUwlUC 
. DE 
70 DF 
71 
EO 
72 : “t iis 
7 3 Se E 1 
{ E2 
74 A E3 
75 B R4 
76 Cc 
77 D ae 
- E6 
78 E7 
79 F ES 
7A G EY 
7B H 


a 
b 
c 

| d 
e 
£ 
8 

| oh 

e! 


Oo YRDUNEFWNrH O 
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Input Marked Mode 


Mode Entry 


input marked mode is entered 


at network generation by the QUEUE command pertaining to the terminal 
queue specifying the parameter IM=MK 


during the communications session to override whatever input mode has 
been declared at network generation 


- either by the network control command MTE senses Tne the terminal 
and the IMARK parameter 


- or by the terminal operator command $*$MTE specifvite IMARK. 


Treatment of Data 


e VIP-headers are translated into mark form and passed to the user buffer. 


header generated by termi- 


logical header nal in VIP line procedure 


data transmitted to buffer 


e Control codes and trailers are translated into mark form and passed to 
the user buffer. 


message keyed in on terminal 


data transmitted 
to user buffer 
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Input Marked Mode 


Treatment of Data 
(continued) 


e Control codes and trailers in mark form are passed unchanged to the user 
buffer. 


message keyed in 
on. terminal 


data transmitted 
to user buffer 


e The character-encoding mark ><C passes the following 2 hexadecimal-digits 
as a i-byte hexadecimal value to the user buffer. 


message keyed in on terminal | 


data transmitted to buffer 


e The repeat mark ><R repeats the graphic symbol, character-encoded hexa- 
decimal value or control code, as a 1-byte hexadecimal value. 


BNDooUesooeeeeee 


data transmitted to buffer 


message keyed in on terminal 


data transmitted to buffer 


e The sequence of the repeat mark followed by a control code in mark form | 
is deleted from the user buffer. 


message keyed in 
on terminal : 


data transmitted 


deleted to user buffer 


e All other character strings are passed unchanged to the buffer, notably, 


e 2<Cxy, where xy is not a hexadecimal value ee 
0 ><Rab, where ab is not a decimal value. | 


s 
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Input Normal Mode 


Mode Entry 


The input normal mode is entered 


« at network generation by the QUEUE command Bepeeiiive to the terminal 
queue | 


- either not specifying the IM parameter, that is, "normal" is the 


default input: mode - 
- or specifying the parameter IM=NL 


~ 


. during the communications session to override what ever popue mode has 
been declared at network generation 3 


- either by the network control command MTE specifying the terminal 
and the INORM parameter 


- or by the terminal operator command $*$MTE specifying INORM. 


Treatment of Data 


e VIP-headers are deleted from the user buffer. 


header generated by termi- 


logical header nal in VIP line procedure 


| deleted , 
data transmitted to buffer 


Except for HIV and ESC, all control codes are deleted from the buffer. 


message keyed in on terminal 


data transmitted to buffer 
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Input Normal Mode 


Treatment of Data 
(continued) 


e Control codes and trailers in mark form are passed unchanged to the user 
buffer. P 


message keyed in 
on terminal . 


data transmitted 
to user buffer 


e The character-encoding mark ><C passes the following 2 hexadecimal-digits 
as a i-byte hexadecimal value to the user buffer. 


message keyed in on terminal 


data transmitted to buffer 


fe] 
@ The repeat mark ><R repeats the graphic symbol, character-encoded hexa- 
peed value or control psa as a aaah peer erena: value. 


data transmitted to buffer 


message keyed in on terminal 


data transmitted to buffer 


e The sequence of the repeat mark followed by a control code in mark form 
is deleted from the user buffer. 

message keyed in 

on terminal 


Aelaced data transmitted 
to user buffer 
@ All other character strings are passed unchanged to the buffer, notably, 
» ><Cxy, where xy is not a hexadecimal value 
e 2<Rab, where ab is not a decimal value. 


‘Input Unedited Mode | 


Mode Ent ry 


input unedited mode is entered 


at network generation by the QUEUE command pertaining to the terminal 
queue specifying the parameter IM=UN 


during the communications session to override whatever input mode has 
been declared at network generation 


- either by the network control command MTE a a oa the terminal 
and the INEDT ‘parameter 


- or ay the terminal operator command $*§MTE spectisie: INEDT. 


Treatment of Data 


e VIP-headers are translated into mark form and passed to the user buffer. 


header generated by termi- 


Peatea® seid nal in VIP line procedure 


data transmitted to buffer 


message keyed in on terminal 


data transmitted to buffer 
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Input Unedited Mode 


Treatment of Data 
(continued) 


e Control codes and trailers in mark form are passed pnchanecc to the user 
buffer. 


message keyed in 
on terminal 


PITT Tttter 


data transmitted 
to user buffer 


e The character-encoding mark ><C, even if followed by 2 hexadecimal- 
digits, does not perform the "'character-encoding" function and is passed 
unchanged to the user buffer. 


message keyed in on terminal 


T 114 


data transmitted to buffer 


e The repeat mark ><R, even if followed by 2 decimal-digits, does not per- 
form the "repeat" function and is passed unchanged to the user buffer. 


Piiiitihiiii itt 


e The sequence of the repeat mark followed immediately by a control code, 
either as a 1-byte hexadecimal value or in mark form, is passed unchanged 
to the user buffer. 


ttete tte tte ee eed dt 
Lest =]e]s bid >i<]efotet>t<fefele 


@ All data is treated as character strings and passed unchanged to the user 
buffer. 
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Processing on Output 


is The 2 transmission modes for processing on output are, 


+ output normal mode 


- output. unedited mode. 


For output normal mode, tables are given for each line procedure, since the way 
in which certain control codes are handled, Sopenee on whether they are appli- © 
cable to the line procedure. | | 


In addition, certain graphic symbols are treated as non-standard, ‘since the re- 
ceiving terminal, like the IBM3270, cannot display them 


For the IBM3270, the following graphic symbols are not displayed, 


3 


3 


> 


98 


BS 


In addition, 


open single quote > 
tilde | 


open brace 


close brace 


back-slash. 


7D displays as an apostrophe (') and not as a close ‘aingte 4 quote ¢ )e 


In each of the output normal mode tables, control odes that are not applicable 
for output for the line procedure, are shown in character-encoded form. 


In this respect, non-applicable control codes are treated in noe same way as 
transmissions for which no graphic symbol exists. 


OUTPUT NORMAL MODE 


Sede neynbel ae TC & TTY LINE PROCEDURES 


Character String 


7 EBCDIC Value 


BOOINUL] 00 fF [Code: Symbol 
O1/SOH} 01 EBCDIC Value or denotes that no control code 
O21ISTX} 02 | Character Strinp cr graphic symbol is present 
O3{ETX; 03 : 


m@ EBCDIC Value 
Code : Symbol 
EBCDIC Value or 
Character String 


fs EBCDIC Value 
ae ><C64 Code : Symbol 
><C65 EBCDIC Value or 
>< C66 Character String 


fEBCDIC Value 
poe >< C90 EF Code : Symbol 
j EBCDIC Value or 
Character String 


><CB8 fH EBCDIC Value 
><CBOR Code : Symbol | 
><CBA EBCDIC Value or 
><CBB - |Character String 


>< CBC 
><cBD 
>< CBE 
><cBF Ey 


co E2 

Cl E3} 
C2 
C3 
C4 


denotes exceptions specific 
to TC & TTY line procedures 


B4r omy moO Ww > Be 
NKM Bcc Hw 


oO WDUPWHPHO 
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OUTPUT NORMAL MODE 


EBCDIC Value | 3 | | 
Code : Symbol ert | - | 
EBCDIC Value or’ s * : BSC2780 & VIP LINE PROCEDURES 
_|Character String a a | | ; 7 = 
| m EBCDIC Value | 
OO|NUL| oO § Code : Symbol | 
O1/SOH{ O1 {| : EBCDIC Value or 
: Character String 


m EBCDIC Value 
Code : Symbol 

, EBCDIC Value or. 
na a 3° ae | Character String 


Or PER ae EBCDIC Value 
a ><C64 Code : Symbol 
><C65, -JEBCDIC Value or 
Character String 


EBCDIC Value 

Code : Symbol 
EBCDIC Value or 
Character String 


m EBCDIC Value 
Code : Symbol 
EBCDIC Value Or 
Character String 


denotes that no control code _ 
cr graphic symbol is present 


| denotes excepticns specific to 
j BSC2780 & VIP line procedures 


Hmrmomm? moan wW Pe 


BOO URUPWHHO 


wo VOZ Brn uw 
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OUTPUT NORMAL MODE 


code: Symbol BSC3270 LINE PROCEDURE 


Character String 


EBCDIC Value 


OO|NUL} OO § Code : Symbol 

01!SOH 01 EBCDIC Value or denotes that no control code 
B02] STX 02 Character String or graphic Symbol is present 

O3;ETX} 03 


1EBCDIC Value 

Code : Symbol 
EBCDIC Value or 
Character String 


gs EBCDIC Value 
Code : Symbol 
EBCDIC Value or 
Character String 


FEBCDIC Value 


denotes exceptions specific 
tc the BSC3270 line procedure 


OC @ 3C;}DC4 
3D | NAK 


I 90 Bees ><COOM = [Code : Symbol | 
91) j 91 EBCDIC Value or 
892) k 92 =«&f Character String 
i 93 # EBCDIC Value 
m 94 Code : Symbol 
n 95 EBCDIC Value or 
re) Character String 
Pp : 
><CDE 
: ><cDF 


ove: : 


Hmom m0 wo bP. 


NK MSc OEE, 


om sau P WHO 


DO VWOZErA u 
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_ Output Normal Mode 


Mode Entry 


The output normal mode is entered | 
e at network generation by the QUEUE command pertaining to the terminal 
queue 


- either not specifying eis OM Peremereny that is, "normal" is the 
default output mode | | 


- or specifying the parameter OM = = NL 


« during the communications session to override the "unedited" mode de- 
clared at network generation 


- either by the network control command MTE specifying the terminal 
and the ONORM parameter 3 


- or by the terminal operator cemaa $*$MTE Specifying ONORM. 


Treatment of Data 


e VIP-headers can be provided in mark form to be passed to the terminal. 
The system provides trailers where none are specified by the user. 


data composed in user buffer 


trailer 


e Control codes, applicable to the line procedure for output, are passed 
unchanged to the terminal. 


trailer supplied by 


ee linn es ee system to terminal 


data composed in user buffer 


message sent to terminal 


e Control codes, not applicable for output, are translated into character- 
encoded form.and sent to the terminal. 


The example follows the 
BSG2780 line procedure 
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Output Normal Mode 


Treatment of Data 
Gone eee) 


e i- ee hexadecimal values, for dhich no graphic symbol or Seareel code 
exists, are translated into character-encoded form 


e Applicable control codes in mark form translate as i-byte hexadecimals. 
Non-applicable control codes in mark form pass unchanged. 

: | Example follows the 

VIP line procedure 


e The character-encoding mark ><C passes the following 2 hexadecimal-digits 
as a 1-byte hexadecimal value to the terminal. 


data in user buffer 


mesSage sent to terminal 


e The repeat mark ><R repeats the graphic symbol or character-encoded hexa- 
decimal value, as a 1-byte hexadecimal value. 


e The repeat mark ><R repeats applicable control codes as 1- ~byte hexadeci- 
mals 3 non-applicable control codes are deleted. 


Examp le follows 
BSC3270 


fps 


e All other character strings are passed unchanged to the terminal, notably, 
« 2<Cxy, where xy is not a hexadecimal value | 
° ><Rab, where ab is not a decimal value. 
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Output Unedited Mode 


Mode Entry 


The output unedited mode is entered 


e at network generation by the QUEUE command pertaining to the terminal 
queue specifying the parameter OM=UN 


« during the communications session to override the "normal" mode de- 
clared at network generation 


- either by the network control command MTE specifying the terminal 
and the ONEDT parameter 


- or by the terminal operator command $*$MTE specifying ONEDT. 


Treatment of Data 


e VIP-headers can be provided in mark form to be passed to the terminal. 
The system provides trailers where none are specified by the user. 


data composed in buffer 


ae | | _ trailer supplied b 
transmission header a  b |erailer ives 3 ata d 
, Ee : system to terminal 


e Control codes are passed unchanged to the terminal. 


data composed in user buffer 


data sent to terminal 
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Output Unedited Mode 


Treatment of Data 
(continued) 


e Control codes and trailers in mark form are passed unchanged to the ter- 


: BSBBABHO EE ‘iene acanae Satilen 


data sent to terminal 


-@ The character-encoding mark ><C, even if followed by 2 hexadecimal- 
digits, does not perform the "character- -encoding" function and is passed 
unchanged to the terminal. 


data composed in user buffer 


; fe dye | 


data sent to terminal 


e The repeat mark ><R, even if followed by 2 decimal-digits, does not per- 
form the "repeat" function and is passed unchanged to the terminal. 


e The sequence of the repeat mark followed immediately by a control code, 
either as a 1-byte hexadecimal value or in mark form, is passed unchanged 
to the terminal. 


@ All data is treated as character Strings and passed unchanged to the ter- 
minal. 
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DATA REPRESENTATION 


GCOS offers the programmer several ways of representing data. depending on such | 
factors as, . | | 


» the type of terminal used, which may involve a special character set ceih BBE. 
-e the complexity of control functions to be activated 


. the provisions to be made for the transition of the MCS application to TDS 
with the minimum of modifications. | 


Graphic Symbols | 
In the 2 examples "Data Representation Using Graphic Symbols'', the data cited is 
valid for any transmission code. | Pe ah | 
Variations in representing graphic symbols are caused by, 

. type of device a 
-» national language options 


- special characters. 


TYPE OF DEVICE 


The character set available to the user, depends on the type of the device that 
is used for data entry, for example, 


. if the data is entered in the form of cards, the only character set eal cag 
is standard EBCDIC, or part of that set allowed on the meypuncn, since ‘ower 
case letters are not represented 


« if, however, the data is entered under IOF, from a terminal having upper and 
lower case capability, that is, having the "shift-in/shift-out' function, 
the character set is greatly extended. 


Conversely, characters are displayed according to the type of the device used to 
display them, namely, the line printer will only display upper case letters, 
even if the data is entered in lower case letters from, say, a VIP7760 terminal. 


NATIONAL LANGUAGE OPTIONS 


The different graphic symbols used for national language options come within the 
category of special characters, with the one basic difference, namely, 


» special characters are used as conventional symbols, peimaeity? 
- to delimit text, such as punctuation signs 
- to qualify text, such as monetary signs to indicate currency 


» national language options, however, are symbols used in ‘the context of read- 
able text in a particular language, for example, % for Danish. | 


The user, in order to ensure correct processing of national language options, 
must specify their equivalents in his applicetion, see "Special Characters" and 
"Numeric Values", 


SPECIAL CHARACTERS 


The DPS 7 CPU internal code is EBCDIC, the graphic representation of which is 
used by local unit record devices, such as, the system console, the card reader 
and/or punch, and the line printer. 


Most terminals, however, use the ISO ASCII code in which the graphic representa- 
tion of special characters differs in some cases from that of EBCDIC. 


This means that the user, in order to display certain special characters on his 
terminal, must specify their equivalents* in his applioation. 


In the ASCII and EBCDIC tables, where 2 graphic symbols appear against the code, 
the graphic symbol on the right is the EBCDIC representeétion. 


Example of Using 
Special Characters 


e Example of special characters rendered differently ; 
EBCDIC graphic, used by GCOS internally : 
ISO ASCII graphic, used by VIP terminals 

@ Text to be eAepreyce on VIP Arena 
VERSION DATED : : 80/03/29 

e What the user must declare in the MCS application: 


DATA DIVISION. | 
77 VERS PIC X(28) VALUE "VERSION DATED : ¢ 80/03/29 !". 


DCL VERS CHAR(28) INIT ("VERSION DATED : ¢ 80/03/29 !"); 


* The term "equivalent" need not necessarily mean the graphic symbol equivalent. 


Numeric values of the special character or national language option are used 
in such cases where there are no graphic symbol equivalents 


~, either on the device for data entry or display 


eo or in the standard character set recognized by GCOS. 


3-27. 


Data Representation 
7 Using 
Graphic Symbols 


To send the text | * HERE IS DATA-ENTRY (80/03/29 VERSION) * 


DATA DIVISION. 


77 START PIC X(41) VALUE "* HERE IS DATA-ENTRY 
(80/03/29 VERSION) *", 


| COMMUNICATION SECTION. ° 


GD CD-OUT OUTPUT. 
only user-initialized CD-output parameters are shown 
DESTINATION COUNT COUNT-OUT 
TEXT LENGTH — LENGTH-OUT | 
DESTINATION DESTINATION-OUT . 


PROCEDURE DIVISION. 


MOVE 1 TO COUNT-OUT. 

MOVE 41 TO LENGTH-OUT. 

MOVE destination TO DESTINATION-OUT. 
SEND CD-OUT FROM START WITH EMI. 


$H_CD OUTPUT , PREFIX='USER ' ; 

only user-initialized CD-output parameters are shown 
USER_DESTINATION_COUNT = 1 ; | 
USER_TEXT_ LENGTH = 41 ; 


USER_QUEUE_NAME = ''destination" ; 


DCL START CHAR(41) 
INIT ('* HERE IS DATA-ENTRY (80/03/29 VERSION) *") ; 


$H_SEND 'ADDR(USER_OUTPUT_CD)', INADDR='ADDR(START)' , 
ENDCHAR = EMI ; 
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Data Representation 
Using 
Graphic Symbols 


To receive the message requesting "end-of-application" 


DATA DIVISION. 


O1 INBUF. 
O02 INB1 PIC X(2000). 
O02 INB2 REDEFINES INB1. 
03 INB21 PIC X(4). 
03 INB22 PIC X(1996). 


COMMUNICATION SECTION. 


CD CD-IN INPUT 


only user-initialized CD-input Eonenere are shown 
TEXT LENGTH LENGTH-IN 


PROCEDURE DIVISION. 


MOVE 2000 TO LENGTH-IN. 
RECEIVE CD-IN MESSAGE INTO INBUF. 
IF INB21="STOP" GO TO TERM-PROG. 


° 
i] 


TERM-PROG « 
$ 
b 


9° 


$H_CD INPUT PREFIX='USER_' ; 
DCL INBUF CHAR(2000) ; 


$H_RECEIVE 'ADDR(USER_INPUT_CD)' , OUTADDR= 'ADDRCINBUF)' , 
LENGTH = 2000 ; 


IF SUBSTRCINBUF,1,4) ="STOP'' THEN GO TO TERM-PROG ; 


e 
. @ 


TERM-PROG 3 3 
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a Representing Graphic Symbols _ 


The 3 ways of representing graphic symbols are, 
aa direct use of erepnts se 
« numeric values 


e mark form. 


DIRECT USE OF GRAPHIC SYMBOLS 


Without exception, all numeric characters and alphabetic capitals are entered 
directly, since these are valid for any transmission code, and for any keying-in 
and receiving devices. 


The previous 2 examples "Data Representation Using Graphic Symbols" illustrate 
the direct use of graphic ayer Orey both on output as well as on input to the 
application. 


NUMERIC VALUES 
Representing the graphic symbol by its numeric value enables the programmer to 
define any code, whether displayable or not. 


By this means, special characters and national language options can be specified 
even at installations where these are not available. 


Application development, therefore, is not restricted in any Ways 
The numeric value is specified according to what is expected by the compiler, 
namely, 
. for the MCS COBOL compiler, the decimal value of the COBOL collating sequence 
« for the GPL compiler, the hexadecimal EBCDIC value. 


National Language Option 
Using Numeric Value 


represent the character @ ; 


Refer to the appropriate terminal manual giving the QWERTY layout for 
the national keyboard options of Denmark or Norway. 


The ASCII value of 9 is 5C. 

The stendard graphic symbol for ASCII 5C is \. 

The numeric value for ASCII 5C is, 
« 225, being the COBOL collating sequence value in decimal 
« EO, being the hexadecimal EBCDIC value. 


e Declare the appropriate numeric value in the MCS COBOL or GPL application 
respectively, if the standard graphic symbol \ is not available. 
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Data Representation 
Using 
Numeric Values 


To send text containing upper and lower case letters 


i. Refer to the EBCDIC table for the COBOL collating sequence 
values for the graphic symbols required. 


2. Declare in the DATA DIVISION either form of coding : 


| 97 DAT PIC X(4) VALUE "D''130, 164,134", 


77 DAT PIC X(4) VALUE ''197, 130,164,134", 


Refer to the EBCDIC table for the EBCDIC values of the 
graphic symbols. 


Code the constant character-sString in EBCDIC values be- 
tween double-quotes followed by the letter H : 


DCL .AB CHAR(4) 3 
AB = "'G481A385"H 3 
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MARK FORM 


Data in mark form is a general facility of MCS, by which any type of data can be © 
represented in an easy-to-use symbolic form, see "Symbolic Representation" at the 
Start of the section. | 
For graphic symbols, the 2 types of mark form dealt with are, 

e ><C, denoting character-encoding 

« ><R, denoting the "repeat" function, 
The choice of entering graphic symbols either in their character-encoded form or 


as their numeric values, depends on the transmission mode which, in turn, is de- 
termined by what the MCS application expects to process. 


As a general rule, where the graphic symbol exists for the code, MCS processes | 
both forms in the same manner, translating the code into its numeric value. 

A numeric value, not corresponding to a displayable code, is output in normal 
mode to the terminal in character-encoded form. 


The "repeat"! function is performed where the character-encoding marks specify 2 


valid hexadecimal digits, and in both cases, that is, character-encoded form end 
numeric value, the code is repeated in its numeric value. 
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Data Representation 


Using Mark Form 
(Character-Encoding & Repeat) 


To send text and a string of 80 asterisks 


Refer to the EBCDIC table for the EBCDIC values of the characters. 


ae For "Date", use either form of coding ; 


| 77 DAT PIG X(16) VALUE "D><c81><cA3><c85". 


| 77 DAT PIC X(20) VALUE "><cc4><C81><CA3 ><C85". 


be For string of 80 asterisks, use either form of coding : 


77 AST PIC X(6) VALUE "><R80*"', | 


a For "Date", use either form of coding : 


| DCL DAT CHAR(16) INIT ("D><c81><cA3><c85") ; 


| DCL DAT CHAR(20) INIT ("><cc4><cB1><ca3><c85") 3 | 


be For string of 80 asterisks, use either form of coding ; 


| DCL AST CHAR(6) INIT ("><Rg0e"); | 
DCL AST CHAR(10) INIT ("><R80><c5C"); | 
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Control Codes 

Control codes: are cenecated by the Peaminel when the touch- -key representing the 
appropriate control function is pressed. , 3 

The programmer, however, encodes these. control functions to send to the terminal 


in order to activate certain terminal management functions. 


While in the majority of casein, the control function is associated with a single 
control code, other more complex control functions are implemented by a control 


code sequence, EEERRECHERS by a combination of control codes and/or graphic sym- 
bols. | | | 


If the user is not concerned with control codes generated by the terminal and 
only wants to activate basic editing functions when sending messages to the ter- 
minal, he should specify the normal mode for both input and output transmission. — 


On input, all control codes will be suppressed from the message text by MCS. 
On output, the user may activate basic editing functions by specifying, 
- the AFTER "advancing" PAGE clause of the [$H_]SEND verb 


« MCS automatic editing functions. 


PEC evn Onn ae 


When the AFTER "advancing" PAGE eiause is used with the last [$H_ ]SEND which 
terminates the message with either EMI or EGI, MCS then automatically generates 
control codes for insertion before and after the message text according to 


» the type of the device receiving the message 
« the control function for the type of terminal management requested. 
In the programming example facing the page, the following actions are performed 
on a VIP7700 terminal, 7 
» to build the screen line by line 


« to generate a "form-feed" function on the last line of the message. 


The following considerations are to be taken into account when coding, namely, 


» the VIP7700 automatically performs a "new-line'' function at the end of each 
line | | 


- the AFTER "advancing'"' PAGE in the last line of the message generates the 
"form-feed" function, a service provided for by MCS. 


The text referred to, to be moved into the output buffer OUTBUF, can be any 
text either for formatting the screen or for displaying form entries. 


Alternative forms of programming are given in both MCS COBOL and GPL examples, 
both of which cater for filling in the entire standard screen of the MEE) 
being 24 lines of 80 characters. 
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MCS 


| COBOL 


DATA DIVISION. 
77 OUTBUF PIC X(80). 
77 IDX COMP-1. 
COMMUNICATION SECTION. 

CD CD-OUT OUTPUT | 
only user-initialized CD-output parameters are shown 
DESTINATION COUNT COUNT-OUT 
TEXT LENGTH LENGTH-OUT 
DESTINATION DESTINATION-OUT « 

PROCEDURE DIVISION. 

MOVE O TO IDX. 

MOVE 1 TO COUNT-OUT. 

MOVE 80 TO LENGTH-OUT. 

MOVE destination TO DESTINATION-OUT. 

move text into OUTBUF and use either form of coding following 


|} LOOP23. 


SEND CD-OUT FROM OUTBUF. 

ADD 1 TO IDX. 

IF IDX < 23 GO TO LOOP23. 

SEND CD-OUT FROM OUTBUF WITH EMI AFTER ADVANCING PAGE. 


| LOOP24 . 


SEND CD-OUT FROM OUTBUF. 

ADD 1 TO IDX. 

IF IDX < 24 GO TO LOOP24. 

SEND CD-OUT WITH EMI AFTER ADVANCING PAGE. 


DCL OUTBUF CHAR(80) ; 

DCL IDX FIXED BIN(15); 

$H_CD OUTPUT , PREFIX='FIRST_' ; 
USER _ DESTINATION COUNT = 1 ;° 

USER | TEXT _ LENGTH = = 80; 

USER | QUEUE _ NAME = "destination" $3 
IDX =0; 


move text into OUTBUF dies use either form of coding following 


| DO IDX=1 TO By 
|| $H_SEND 'ADDR(FIRST_OUTPUT_CD)', INADDR= 'ADDR(OUTBUF)' ; 


|| END 3 
|| $H_SEND 'ADDR(FIRST_OUTPUT_CD)', INADDR= 'ADDR(OUTBUF) ' 
ENDCHAR=EMI , AFTER , PAGE; 


|{ DO IDX=1 TO 24; 


|| $H_SEND 'ADDR(FIRST_OUTPUT_CD)', INADDR= 'ADDR(OUTBUF)' 
|| END 3 | | 
}] $H_SEND ‘ADDR(FIRST_OUTPUT_CD)', INADDR= ‘NULL()* 


ENDCHAR=EMI , AFTER , PAGE 5 


MCS AUTOMATIC EDITING 

Automatic editing functions provided for by MCS are activated through the foll- 
owing parameters of the QUEUE command which apply specifically to the terminal- 
queue and are declared at network generation, namely, 


- BLOCKING : MCS keeps track of the logical line-length specteied by LLENGTH 
in order to generate automatically a new-line or carriage-return/ 
line-feed before the first line of each output ME aRagS or at the 
Start of a new logical line 


« LLENGTH  : Specifies the number of characters in the logical terminal line. 
| | length to be used for automatic ectetne when BLOCKING is speci- 
fied 


« NBLOCKS :; Defines the number of logical lines to be accepted iuceach meses 
age sent to the terminal declared, where the number of characters 
for each logical line is determined by LLENGTH. 


If the message is greater than NBLOCKS- x LLENGTH, dhe characters in excess are 
truncated. 7 


Representing Control Codes 
Control codes are represented by 
« numeric values 


» mark form 


Control code sequences are a combination of control codes and/or graphic symbols. 


NUMERIC VALUES 
In the example opposite, the numeric values for the control codes CRV and LFV are 
specified in accordance with what is expected by the compiler, namely, 
- for the MCS COBOL compiler, the decimal value of the COBOL collating sequence 
« for the GPL compiler, the hexadecimal EBCDIC value. 
In GPL, no intermixing between graphic representation and hexadecimal values is 
allowed, and for that reason, control codes to be filled in must first be init- 
ialized as spaces.in the constant character Strings 
The example also shows the formatting of the VIP-header and its parameter codes. 


The mark form ><UO3 is the invariable VIP-header and can be regarded as a speci- 
al case of the control code in mark form, which is, 


- delivered on input in front of the message text from the terminal 
° provided on output in front of the message text by the user 


» allowed in the unedited mode, both on input and output, in order for the pro- 
grammer to access the Status and function EOeer: 
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Control Code 
Se quence 
Using Numeric Values 


BOOKINGS 
NUMBERS : 


To send to the VIP7700 printer the text format 


1. To address the VIP7700 printer, use the following values for the VIP- 
header. | 


STA=3F (EBCDIC value) 
=64 (COBOL Collating Sequence) 


FC1 and FC2 to be left initially as spaces 
re format of che ir tener 19 [>] <]o ] | 3 [om feifce 


2. To position the hard copy for the second line of text, use the values: 


CRV=OD (EBCDIC value) 
=14 (COBOL Collating Sequence) 


LFV=25 (EBCDIC value) 
= 38 (COBOL Collating Sequence) 


3. In the MCS application, code as appropriate : 


For MCS COBOL, use the COBOL collating sequences 
DATA DIVISION. 


77 HEAD PIC X(26) VALUE "><U03"64''VVBOOKINGS'"'14" 
"38"NUMBERS: ''. 


| For GPL, use the EBCDIC values © | 
}. DCL..HEAD CHAR(26) INIT ("'><UO3V-VVBOOKINGSVVNUMBERS: "") ; 


SUBSTR(HEAD,6, 1) ="3F"H ; 
SUBSTR(HEAD, 17,2) ="0D25"H ; 
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-. MARK FORM | 

‘The mark Poemueuanien any control ‘eae known to “the eaeTeem PEceae ges to be 
entered in its mnemonic form | | 
This easy-to-use. symbolic representation. of control codes is a general facility 
of MCS. _ ye 
For the control code sequence, the 2 types of mark form dealt with are, 

« ><ccc, where ccc represents the 3-character mnemonic of the control code 

« O<C, denoting character-encoding for the EBCDIC numeric value to follow, 


thereby completing the control code sequence. 


The "repeat" function is not treated here, since the processing of "repeated" 
control codes, in whatever form, is specific to the line procedure, see "Control 
Code in Mark Form" and "Character-Encoded Form!'' on page 3-04. 


The choice of entering control codes either in their: character-encoded form or 
in their mnemonic mark form, depends on the type of control code. 


In general the control code or the control code sequence is Bapee ores in charac- 
ter-encoded form, under the following conditions, 


» when the control code is not defined as standard, see "Control Codes" 


» when the control code Sequence is composed of data which individually is 
neither control codes nor graphic eyeners i: and therefore, cannot Oe epeci= 
fied in any other form 


Control Code 
Sequence 
in Mark Form 


To position the cursor of the VIP7700 screen on line 11 at column 37, 


1. Refer to the VIP7700 terminal manual for the format of the command to 
position the cursor. — 


command is DC3ab, where, a is the line number 


b is the column position 


2. Refer to the ASCII table to determine the values for line and column. 


To determine the EBCDIC value for line 11, proceed as follows, 
e Start from ASCII code 20 which is a "Space" . 
e Count 11 codes from the ASCII code 20 
» The ASCII code arrived at is 2A or graphic * 
e The EBCDIC equivalent is 5C | 


To determine the EBCDIC value for coluntn 37, proceed as follows, 
« Start from ASCII code 20 which is a "space" 

« Count 37 codes from the ASCII code 20 

» The ASCII code arrived at is 44 or graphic D 

o The EBCDIC equivalent is C4 — 


3. In the MCS application, use either coding: 


77 CONT PIC X(7) VALUE "><DC3*D". 
77 CONT PIC X(1i5) VALUE "><pCc3><c5c><cCC4". 


DCL CONT CHAR(7) INIT ("><DC3*D") ; 
DCL CONT CHAR(15) INIT (''><DC3><C52><CC4") ; 
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SECTION IV 


CONNECTION HANDLING 


Connection handling describes the dynamics of establishing the connection between 
users, represented by terminals and applications. 


The connection interface between both local and remote users, is assured by the 
Message Control System, whose functions are provided by MAM and QMON. 


Once the connection has been established, data exchange can then take place. 


Whereas the connection in the case of VCAM subsystems is direct, the connection 
in the case of MCS applications is logical, in order to allow for the following 
conditions, 


» the application can be connected to an output queue whose pereayectee termi- 
nal is not active : 


eo the terminal can be connected to an input queue whose associated application 
is not executing. 


The term "local terminal" refers to a terminal connected over secondary networks, 
that is, both the local and the TRANSPAC secondary networks accessed over BINS. 
The logon for terminals configured over these secondary networks is treated in 


detail in the Terminal Operations Manual. 


The term "remote application" refers to an application executing in a machine oth- 
er than the DPS 7 local system This other machine can be connected to the local 
DPS 7 either over the secondary network through the BSC2780 line procedure or over 
the primary network. In the case of the primary network, the local DPS 7 acts ei- 
ther as the "host!" over the FNPS/DN7100 interface or as the "Satellite" over the 
TNS/URP interface. 


A comprehensive description of Distributed Systems Architecture and DPS 7 networks 
is given in the Communications Overview Manual. 


This section is intended to describe how the various types of network connections 
are handled and the effects of the $QASSIGN statements in each case. For details 
on $QASSIGN, see pages 2-05 through 2-53. 


The conventional symbols in the text are as follows, 


GCOS process | @ terminal mailbox as "end-point" 

- BINS and FNPS x 

- QMON *) applicatiori mailbox a as "end-point'! 
GCOS access method A MCS queues . 

~- MAM - T terminal-queue ; P program-queue 


- VCAM | - Nx. Py DSA-queue <system queue> — 
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Machine A: System NA 


The diagram shows the relationship between 
the various types of queues constituting 
the communications links supported by MCS. 


Mailboxes are omitted for reasons of sim- 


plicity and are treated in detail for each 


individual case of connection handling. 


Case c is a particular example of terminal 


handling in the URP local network where 


Machine B is a CPU connected to Machine A 
uSing the BSC2780 line procedure. 


Case d shows connection handling over the 
primary network using the FNPS/DN7100 in- 


terface of Machine A and the TNS/URP interface of Machine C. 


References in the text following, are 


(a) 


(b) 


(c) 
(d) 


see "Manual Logon from a Local Terminal to a Local Application" 


see "Logon from one Local Terminal to another Local Terminal" 


see "Communication between Remote Applications", 


Section IT 


see "Connection Request from a Local Application to a Remote Application" 
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The term "machine" refers to the DPS 7 either as a system in a DSA primary net- 
work or as an HL64 CPU terminal in a secondary network. 


The term "application" is used to group together VCAM subsystems and MCS applteae 
tions. 


During the logon of a general-purpose terminal, the operator keys in, in response 
to APPL, either the name of the VCAM subsystem or the name of the program-queue 
denoting the MCS application, see "Logon Procedures", Telecommunications Ref. Card. 


Besides local applications communi cating in the same machine, the Message Control 
System supports other communications links, shown in the diagram opposite, which 
are the following, in relation to the machine in which they occur, 


e over the BINS/URP interface in a secondary network 


(a) Machine A : | | 
- between the application PA, represented by the program-queue PA 
- and the terminal T2, represented by the terminal-queue T2 


‘(b) Machine A : 
- between the terminal Ti, represented by the terminal-queue Tl 
- and the terminal T2, represented by the terminal-queue T2 


(c) Machine A linked up to Machine B, using the BSC line procedure : 


~ between the BSC terminal T3, represented by Machine A, and the ap- 
plication PB, situated in Machine B 


- and, between the BSC terminal T4, represented by Machine B, and the 
application PA, situated in Machine A 


e in a primary network using the FNPS/DN7100 interface of Machine A on the one | 
side, and the TNS/URP interface of Machine C on the other side. 


(d) Machine A linked up to Machine C, as systems in a DSA network, where A 
and C are respectively the systems NA and NC : 


- between the DSA-terminal-queue NC. PC, ener Machine A as Sys- 
tem NA, and the application PC situated in Machine C as system NC 


- and, between the DSA-terminal-queue NA. PA, representing Machine C as 
System NC, and the application PA situated in Machine A as system NA 


Connection handling is dealt with in terms of 
e connection request from a local terminal 
» connection request from a local application 
e connection request from a remote application. 


For local applications, see "Communication between Local Applications", see 
Section II. 
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: CONNECTION ‘ 


‘The cases considered for connection requests from a local terminal are, 

» manual logon from a local terminal to a local application | 

e logon from an automatic-dedicated - ‘terminal to.a local application es 
° logon from an automatic terminal to the QMON mailbox. 

« manual logon to a "blank" destination or to the QMON mailbox 


e logon from a local terminal to another local terminal. 


Manual Logon from a Local Terminal to a Local Application 


The local terminal referred to in this instance is a general-purpose terminal, 
that is, declared at network generation with neither AUTO nor ASSIGN. 


Such a general-purpose terminal can communicate with any MCS eppttearten through 
a program-queue defined at network generation. 


The connection is rejected if the following anomalies occur, 


. CCO4 LOGON DENIED : SECURITY CHECKS FAILED 


- one or more of the specified catalog parameters, for a validated GCOS 
site-catalog, given in reply to the CCO1 message is incorrect. 


e CCO4 LOGON DENIED : APPL REJECT 


- the specified MCS program-queue has neither been defined nor enabled, or 
is saturated at the time of the connection requeSt. 


- one of the following terms has not been defined, 
e a terminal-queue bearing the same name as the terminal-mailbox 
e a uSerid-queve bearing the same userid of the terminal operator. 


~ the terminal-queue or userid-queuve is not available since some executing 
application has a §$QASSIGN OUT on the terminal concerned but does not 
have a $QASSIGN IN on the designated program-queue. 


—- 4-04 


Manual Logon 


from a Local Terminal 
to a Local Application 


MCS 
application 


terminal 
T 


JCL for the MCS application, if executing at logon time, must contain :. 
» $QASSIGN IN on the program-queue P — 
e and, optionally, $QASSIGN OUT on the terminal-queue T 


1.a Terminal T requests connection through manual logon to the MCS. program- 
queue P, specifying P as the application. 


1.b The BINS terminal handler initiates the logical connection between the 
terminal-mailbox T and the application-mailbox P, which has the same 
name as the MCS program-queue P. 


1.c The connection is accepted by QMON when all conditions are satisfied, 
that is, | 
» if catalog access rights have been validated 
- if the program-queue P is defined, enabled and not saturated 
e if the terminal-queue or userid-queuve is defined and available. 


i1.d Data exchange can now take place. 


| 22 Messages sent by the terminal T are placed by QMON into the program- 
queue P and from there retrieved by the MCS application for processing. 


3. Messages sent by the MCS application are placed in the terminal-queue T 
and from there are retrieved by QMON for transmission to the terminal T. 


While the connection is established, any assign request on the terminal- 
or userid-queuve through $QASSIGN OUT, will be rejected. 
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Logon from an Automatic Dedicated Terminal tes Local A lication 


re eibeuseieteieaees . eetinal is phe where both the AUTO and ASSIGN options 
have been declared at network generation. 


_ The connection request is. automatically handled by the BINS terminal manager © 

which acts on behalf of the terminal as soon as the terminal is powered on and 
no HT network control command has been previously issued to the terminal or to 
any component of the link. : 


The userid generated by the secondary network controller for the terminal has 
the syntax <gencom-name><terminal-name> or <lsys-name ><terminal-name>. 


In order for catalog access rights to be established for such a terminal, the 
project of this userid must specify in its CRP command of the CATMAINT utility, 
the program-queue in its APPLIST, see System Management Guide. 


The only logondialogis inthe case where the terminal is connected over a switch- 
ed line and declared with the IDSEQ command at network generation. 

The BINS secondary network controller then sends the message CCOO ID?, to which 
the operator replies with the appropriate id, specified in the IDSEQ command. 


Logon from an Automatic Terminal to the QMON Mailbox 


An automatic terminal is one where only AUTO has been declared, and not ASSIGN. 


Such a terminal will be placed in the "logged" state by the BINS terminal manager — 
and will then be available for allocation to any application which requests it. 


Before being placed in the "logged" state, however, the connection request is 
addressed by BINS to QMON, to check if there is any output available in ene: ter- 
minal-queue. 


If the cerminal- -queue has data, and is enabled, the connection is then establish- 
ed between the terminal-mailbox and the QMON-service-mailbox, QMONMBX. 

Once all data has been released to the terminal, and if no $QASSIGN OUT is ae 
ing on the terminal-queue, the connection is broken, and the terminal is set back 
to the "logged" state. : . 


If, however, the conditions for output to the terminal ere not satisfied, the 
terminal will immediately be placed in the "logged" state. | 


As in the case of the automatic-dedicated terminal, the only logon dialog occurs 
for a terminal connected over a switched line and declared with the IDSEQ com- 
mand at network generation. 

The BINS secondary network controller ehen sends the message CCOO ID?, to which 
the operator replies with the appropriate id, specified in the IDSEQ Somnedd 


Manual Lo on to a "Blank" Destination or to the QMON Mailbox | 


The difference between this case and the preceding automatic terminal, is 
« while the terminal is set to the "logged" state, if no output is available, 


the terminal is set to the "idle" state, after data has been output to it. 


Manual Logon 


to a "blank'! Destination 
or to the QMON Mailbox 


terminal 
T 


| This type of connection is initiated by one of the following operator actions, 
e where no application has been specified 
o where QMONMBX, being the system reserved name of the QMON service-mailbox, 
has been specified as the application. 


1. Where no application has been specified at logon, the connection between 
the terminal-mailbox T and the QMON service-mailbox, QMONMBX, will be es- 
tablished, when both conditions are fulfilled, namely, 


e if a default application has not been specified for the project 


» if there are messages available in the terminal-queue T. 


Where QMONMBX has been specified as the application, the connection will 
be established when the second condition is fulfilled. 


2. Once the connection is established, messages are transmitted from the ter- 
minal-queue T to the terminal T. 


The connection is terminated, when all messages have been sent to the ter- 
minal, and no $QASSIGN OUT on the terminal-queue T is pending. 
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Logon from one Local Terminal to_ another Local Terminal 


iésctar 4 a paving? onto snethar enables data to be exchanged between the two ter- 
minals concerned. | | 


The terminal-queue of he terminal receiving the dota becomes the input queue for 


the terminal sending the data. 
In the diagram opposite, the terminals have the edlleniKs seeetuness, 


¢ Tl is a general-purpose terminal, which at logon, is able to specify T2 in 
reply to the option APPL 


» T2 is either an automatic or wit unehecdeatcadad pesuraats which at logon is 
set to the "logged" State, in order to receive the data placed in its termi- 
eae by Tl. 
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"logged" state 


Logon 


from one Local Terminal 
to another Local Terminal 


terminal 


terminal 
T2 
AUTO 


Conditions : ae Terminal-queues T1 and T2 must both be defined and available. 


1. 


2e 


30 


4. 


be There must be no $QASSIGN OUT pending on either terminal- 
queue, Ti or T2. 


c. Terminal T2 must be in the "logged" state. 


At logon, terminal T1 specifies T2 as the application, where T2 also 
serves to identify the terminal-mailbox as well as terminal-queue. 


The first connection is made between the terminal-mailbox Tl and QMONMBX, 
being the system reserved name of the QMON service mailbox. 


If terminal T2, at this stage is not "logged", only this first connection 
is made, thus allowing terminal Ti to send messages to terminal-queue T2. 


The second connection is then made between QMONMBX and the terminal-mail- 


- box T2, if terminal T2 is "logged", when the first message is sent from 


Ti to T2. 
Once these 2 connections have been established, data submitted by terminal 


T1 into terminal-queuve T2, will be retrieved by QMON for transmission to 
terminal T2. 
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CONNECTION REQUEST FROM A LOCAL APPLICATION | 


The connection between two local applications is dealt with in Section II, which 
outlines the communication between two applications in the same central processor, 
namely, 


itl dddlaiatveeksianiat ntiihleaile 

¢ application communicating with itself 

° communication between processes of a multiprocess application. 
In this section, the two cases considered ee connection requests 7ou a local 
application are, 

« to a local terminal 


» to a remote application. 


Connection Request from a_ Local Application to a Local Terminal 


The network prerequisites are that the terminal T, its terminal-queue T and the 
_ program~-queue P must be declared by the TERMNL and QUEUE commands, one for each 
queue, respectively, during network generation (CNC). 


The connection is seeabiieted between the terminal -mai lbox T aad the application- 
mailbox P, when all events occur, | | 

« the application P sends the first sesbase to the terminal-queue T 

« the terminal - queue is enabled | | 

e the terminal is in the "logged"! state, for one of the following reasons, 


- it is either an automatic or automatic-dedicated terminal, which at logon 
will be set to "logged" 


- it isa general-purpose terminal "logged" on to either a "blank" desttes: 
tion or to the QMON-service-mailbox, QMONMBX. 


Data transfer can only occur when the connection is established. 
Messages will be placed by the application into the terminal-queue, and will re- 
main in the terminal-queue, if the connection cannot be made for either reason, 


« the terminal-queue was disabled, in which case, the connection attempt will 
be made when a ($H_)ENABLE OUTPUT is executed on the terminal-queue 


« the terminal was not in the "logged" state, in which case, the connection at- 
tempt will be made when the terminal is set to "logged" from any unapplicable 
State, such as "powered-off"', "held" or "idle", 

Disconnection will take place when one of the following conditions occur, 

« at the request of the terminal, namely, logoff 

-. on the failure of any component constituting the physical link 


¢« on termination of the application and when the terminal-queue has released 
all its messages to the terminal, 
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-“Connection Request 


from a Local Application 
to a Local Terminal 


MCS 
application 


terminal 
T 


JCL for the MCS application must contain 

© $QASSIGN OUT on the terminal-queue T 

e and, optionally, $QASSIGN IN on the program-queue P, see 1.b and 3.b. 
1.a The connection between the application-mailbox P and the terminal-mail- 


box T is established for data transfer where both conditions defined 
above are fulfilled. 


1.b If, however, no $QASSIGN IN has been declared on the program-queue P, 


the connection will instead be established between the QMON service mail 
box QMONMBX and the terminal-mailbox T. 


2e Messages sent by the MCS application are placed in the terminal-queue T 
and from there are retrieved by QMON for transmission to the terminal T. _ 


3ea If the connection described for 1.a has been established, messages sent 
by the terminal T are placed by QMON into the Pecerem-queve P. 


30b Tf the connection described for i.b has been established, — terminal 
T functions as a "receive-only" terminal. 
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Connection Request 
from a Local Application to a Remote ‘Application 
(CNG Declaration and Link-up) 


” S *, 
eeecsoes ‘, 
es se es eee Rees ons eecenees 
See eae eee : 
atossterstonptenetatotasseetehet =” non mon ene 
: olgueereanecs . 
“ 


01:02 


CNC Declaration for System N2 | CNC Declaration for System N1 


QUEUE P2...; | | QUEUE N2.P2.06 ; 


LSYS N11; 
LSC SCID=02:02; 


FNP Fl CCO1; 


LSYS N2; 
LSC SCID= O1: O01 TS=N2TS ; 


RSYS D1; 


RSC D1 SCID=01:02 TS=DITS; FSYS D135 


FSC D1 SCID=01:02 FNP=F1; 


RSYS Ni; | | RSYS N2; 
RSC Ni SCID=02:02 TS=DITS; | RSC N2 SCID=01:01 FNP=F1; 


° The conditions for the connection request to be successful are, 


« » For System N1, 
- its front- and processor must be "Loaded" and its FNPS service must be 
activated through the "MIF D1 AUTO" network control command 
- its program-queue P1 and DSA-cqueue N2.P2 are both "enabled" 


. For System N2, 
- TNS of its BINS/HDLC service must be activated through cis ST command 
- its program-queue P2 and DSA-queue Ni.P1 are both "enabled". 


© Where the connection is unsuccessful, either application can issue a repeat- 
ed sequence of ($H_)DISABLE OUTPUT - ($H_)ENABLE OUTPUT verbs to the DSA- 
queue of its correspondent. 


© The connection remains active until terminated by either correspondent, 
» on "holding" its program-queue through the HT network control command 
- on execution of ($H_)DISABLE INPUT without TERMINAL on its program-queue 


e on termination of the application and when its DSA-queue has released all 
its messages to the other application of its correspondent. : 
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Connection RequeSt — 


from a Local Application to a Remote Application 
(Run-time JCL and Execution) 


N2 N1 
system system 


MCS 
appl 


A\[n2. P2 
Pi 


Conditions : e For system Ni, the JCL for the MCS application Pi must contain 
« $QASSIGN IN on program-queue Pi 
eo $QASSIGN OUT on DSA-queue N2. P2, 


e For system N2, the JCL for the MCS application P2 must contain 
e $QASSIGN IN on program-queue P2 
eo $QASSIGN OUT on DSA-queue Nl. Pi. 
1. QMON in both systems N1 and N2 establish the "link-up" between the applica- 
tion-mailbox Pl in system N1 and the application P2 in system N2. 
The connection between the 2 mailboxes in both systems enables data trans- | 
fers, described in 2 and 3. i 
2e The MCS application in system Ni sends data from its DSA-queuve N2.P2 to 
System N2. | 
QMON in system N2 then places the data received into the program-queue P2. 


3. The MCS application P2 in system N2 does likewise in the reverse direction. 


QMON in system N1 then places the data received into the program-queue Pl. 
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CONNECTION REQUEST FROM A 4 REMOTE APPLICATION 


“sCoakection ending: is pois Same as that for the connection request from a “local , 
application to a remote application. — 


In this case, however, it is the remote. application that initiates the connection 
request, and aS a consequence, the program-queue and the DSA-queue of the local 
application must be enabled in order for the connection to be successful. 


Where the connection is unsuccessful, it is the remote application that must 

issue a repeated sequence of ($H _) DISABLE OUTPUT - ($H_ YENABLE OUTPUT verbs to 
its DSA-queue in ence) to reinitiate the connection request to the local applica-_ 
tione 
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SECTION V 


LINE PROCEDURES 


Line procedures are used to establish transmission protocols over the link,. 
which comprises the network support for the logical connection of two end-users, 
namely, 


e between the DPS 7 as the local system 

- and terminals of the secondary network. 
Terminals supported by GCOS are divided into groups, each group corresponding 
to its specific line procedure. 
Terminals within a group are compatible with each other Since they conform to a 
common transmission protocol. 
A terminal can, in some cases, be supported by more than one line procedure, for 
example, 


« DTU7171, TN1200 and TTU8124 are supported by the TTY line procedure with the 
reverse channel version, TTY-R, as an alternative 


© BIT7300 is supported by the synchronous and asSynchronous versions of the VIP 
line procedure 


© HL64 is supported by both the BSC2780 and the HDLC line procedures. 


Terminals are compatible when they function as follows, 
« from the point of view of hardware and firmware, 
- they share the same TCT, translation code table 


- they are connected over the same multipoint line when using the "poll/ 
select" facility 


e from the point of view of the application, 
~ they share the same controls for formatting the character image. 
In this section, the information regarding transmission control codes is as foll- 
OWS , 


eo .where the mnemonic form does.not appear in the list of "Control Codes" on 
page 3-03, the EBCDIC value is given, see pages 5-06 and 5-07 


e where the control code is internal to the line procedure, it is shown coded 
in mark form, acceptable to MCS, see pages 5-13 and 5-17 


° where the control code is shown in mark form and is present in the list of 
"Control Codes", its corresponding EBCDIC value can also be used instead, see 
"TTY Line Procedure" and Section VI. : 
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The line oe ee es whies the terminal ialcna®, determines its operability, 


namely, 


. the controls used to terminate the message 


« the special characters used to erase message text. 
For this information, see Terminal Operations Manual. 


In the following section, "Programming Terminals", the line ‘ean supporting 
each terminal is indicated in the heading. : 


User visibility in programming the terminals listed in Section aE is limited to 
the control codes by which the terminals function 


Apart from the BSC line procedure, transmission pEekorgr is seen only at syatem 
level. | 


In the BSC line procedure, the user has access to the transmission control codes” 
in formatting his message. 
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BSC2780 


The following processors, known by their CNC declarations as underlined in the 
list, operate on the BSC2780 line procedure with the DPS 7, 


) 


HL61 for 61/DPS 

HL62 for DPS 4 

HL64 for DPS 7/xO and DPS 7/x5, where x is a decimal digit 
HL66 for DPS 8/88 | 

IBM370 for IBM360 and IBM370 

1BM3741. 


GCOS communications software provides the user with the facility for data ex- 
change between the DPS 7 local system and any of the central processors listed 
above, over 


private or leased point-to-point lines, using the BSC1 version of protocol 


switched point-to-point lines, using the BSC2 version of protocol. 


The link provides the facility for applications to communicate with each other, 
see Section IV, "Connection Handling". 


As the facility only concerns application-to-application communication, this line 
procedure does not include automatic processing of end-to-end control codes de- 
fined for the BSC2780 IBM-type terminal, namely, | 


] 


° 


ESC escape, output device selection 
HT horizontal tabulation, positioning 


EM end-of-medium, variable data length delimiter. 


Since these control codes appear within the uSer text, they can be handled di- 
rectly by the MCS application. 


The procedure is described in terms of 


@ 


link states 

logon procedure 

encoding data 

general format of data messages 

management of data transfer by the application 


contents of uSer messages. 
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BSC2780 
continued 


LINK STATES. 


Except where explicitly defined, the state of the link is completely controlled 
by the system through BINS and the URP firmware. The state of the link between 
two Stations using a common communications Facility determines their connection 
and data exchange. 


The link can be in one of the éavicuins states, 
» disconnected state 
e control state 


» message transfer State. 


Disconnected State 


The link can be in the  Gipeeunecwea State only in a switched network environment. | 
This state prevails when | 

« the physical path is not currently established over the network 

« the dial-up procedure is in progress but not yet completed — 


the "disconnect" control sequence DLE. EOT has been issued when the link has 
been idle for longer than the inactivity time-out. 


The disconnected state is entered from one of the other two states. However, when 
leaving the disconnected state, the link always enters the control state. 


Control State 
The link - is in the control state when the corresponding physical data path is 
present but no data transmission is taking place. « 4 


The physical data path is established after the successful completion of the con- 
nection phase at line initialization. 


In the control state, one of the two conditions can occur, 
e absence of transmission 


« initialization of transmission. 


ABSENCE OF TRANSMISSION. 


When transmission does not take place, the link is idle and the way in which the 
link is configured in the network determines 
« how the network handles the idle condition 


« the action taken by the DPS 7. 
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BSC2780 
continued 


If the link is supported by a permanent point-to-point type connection, the idle 
condition persists until the transmission phase is initialized. 

When this transmission phase is started, the DPS 7 monitors the line for as long 
as the link Stays open. 7 


If the link is operated over a switched network, the idle condition will be en- 
tered from the disconnected state on successful completion of the dial-up proce- 
dure. 

The DPS 7 will then monitor the line until a "disconnect" control sequence is is- 
sued for inactivity time-out. 


INITIALIZATION OF TRANSMISSION 


The initialization and termination phases of transmission, between which infor- 
mation exchange takes place, are executed in the control state. 


Information exchange involves the transmission of control blocks and reply blocks 
between two Stations. 


Contention between two point-to-point stations arises when both bid for the line 
at the same time in order to transmit. 


The station wishing to transmit bids for the line by sending the ENQ control code 
aS a transmit request to the other station | 

If the request is accepted, the link is brought into the message transfer state 
and the requesting station can then transmit. Otherwise, the link remains in the 
control States. 

If the request is rejected, bidding for the line is retried up to three times. 


BINS, in its turn, starts bidding for the line each time a new output request is 
made to it while the line is idle. . 

If the line is in the logical "open" state, BINS accepts a transmit request over 
ite 

In order to resolve contention, one of the Stations is designated the "primary" 
station, while the other is designated the "secondary" station. 


Attributes of designating priority to the stations are as follows, 
e if simultaneous line bids occur, the "primary" station transmit first 


© at each bidding, the "primary" station can retry up to three times, and will 
persist to bid until it receives an appropriate reply : any ENQ control code 
received by the "primary" station once it has taken action to request the 
line will be ignored 


« the "secondary" station must respond to all valid END control codes that it 
receives | 


. before re- issuing the transmit request, the "primary" Station has a shorter 
time-out when waiting for a reply than the "secondary" station, thus forcing 
both stations out of contention. 


According to the URP firmware generation, the HL64 can be defined either as a 
a or "secondary'' station. 
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- BSC2780° 
continued 


% INITIALIZATION OF TRANSMISSION (continued) 


The functions applicable to the control state for initializing transmission are, 


| ACKO able to receive, also used for line "turn-around" 
EBCDIC 1070 


ACK1 able to receive, also used for line "turn-around" | 
EBCDIC 1061 


ENQ can you accept transmission? : also used for line "turn-around" 
EOT no synchronization 

NAK unable to receive, also used for line "turn-around" 

PAD time-fill 

7 EBCDIC FF 


RVI you stop transmitting and accept my messages 
EBCDIC 107C 


SYN start synchronizing, also used as "discard" character 


TTD transmission to begin pease sceeuoge Nace NAK or WACK 
EBCDIC 022D 


WACK request later and wait until acknowledged, also used for line "turn-around" 
EBCDIC 106B | 


Message Transfer State 


The message transfer state is a dynamic state which prevails as long as messages 
and the replies they generate are transferred over the line. 


The state is entered at the start of the first message by the start control se- 
quence SOH STX or DLE STX and will be maintained throughout the entire trans- 
mission until the last message ended with ETX has been successfully transferred. 
An end-of-transmission control code EOT is then issued to reset the link to its 
control state. 

The return to the control state can be achieved by the MCS roe through 
KCO or BCO. 


In the message transfer state, the station can Cunetion in one of two ways, 


« as a "master" station, which transmits control codes and block-check's con- 
taining redundant information for verification purposes 


e as a "slave" station, which receives data and transmits replies. 


Station functions are interchangeable and are maintained for as long as the link 
Stays in the message transfer state. 7 


For error free transmission, the "master" station is responsible for resetting 

the link on termination. | 
However, if an error condition occurs, whereby transmission can no longer ocess 
ceed, either station can reset the link to discontinue dialog. 
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BSC2780 
continued 


The functions applicable to the message transfer state during transmission are, 


ACKO 


ACK1 


DLE 
ENQ 


even block received OK, also used for line "turn-around"! 
EBCDIC 1070 


odd block received OK, also used for line "turn-around" 
EBCDIC 1061 


Start-of-transparent -mode 


enquiry, also used for line "turn-around" 
e if between blocks, repeat last response 
- if at the end of block, ignore block and respond with NAK 


cease synchronizing and return to control state, text invalid 
end-of-block, also used for line "turn-around"! 
end-of-text, also used for line "turn-around'! 


end-of-intermediate-record 
EBCDIC 1C 


end-of-intermediate-record 
EBCDIC iF 


block does not check, retransmit, also used for line "turn-around" 


time-fill 
EBCDIC FF 


message received OK : I would like to transmit 
EBCDIC 107C 


start-of-block header 
Start-of-text, starts the first block 
Start synchronizing, also used as "discard" character 


transmission to continue later, respond with NAK or WACK 


_ EBCDIC 022D 


current block received OK : request later and wait until acknowledged, 
also used for line "turn-around" 
EBCDIC 106B 
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continued at wo ee eH 


LOGON PROCEDURE 


An easy way to establish the logical connection between a remote station and a 

_ program-queue is to dedicate the station to the queue, that is, the correspond- 
ing TERMNL command describing the remote station must be declared with AUTO, for 
automatic logon, BES ean ehy: for dedication to the program-queue, at network 
generation. 


The connection is chen established as soon as the line is in the control State 
and remains until the line returns to the disconnected state. | 
For an HL64-to-HL64 connection, the link-up may be established on both sides. 


If the user wants the remote Station to be connected to different applications, 
that is, to different program-queues, the corresponding TERMNL command describ- 
ing the remote station must only be declared with AUTO. 


In this case, once the remote station is "logged", it eee. be available for al- 
location to any eppatceesn which peace ite 


ENCODING DATA 

Functionally the BSC2780 sep Ketosol dilews two categories of user-provided da- yi 

ta to be exchanged over the line, namely, | | 
» text, comprising data to be processed 


. heading, containing information for ee end control. 


Text 


Although ASCII encoding is a function of the BSC2780 line procedure provided 
through the TCTNM parameter of the appropriate LINE command, exchanges between 
Series 60 processors are performed in EBCDIC code, this internal code being the 
default option. 


For more efficient recovery purposes, text may be split ; into Subp lecie separated 
by sequences of control codes irrespective of the mode of transmission. 


Depending on the requirements of the application, text may be transmitted in one 
of the following modes, | 


e normal mode 


e tranSparent mode. 
hee MODE 


Text tranSmitted must not contain any control codes or control Be qucHeee used by 
the protocol of the BSC2780 line procedure. | 
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BSC2780 
continued 


TRANSPARENT MODE — 


The text may contain unrestricted coding of data since all control codes includ- 
ing the "escape'' control code DLE must be preceded by DLE in order to be recog- 
nized as a control function 


The 
DLE 
DLE 


Heading 


control functions that can be specified in transparent mode are, 


DLE 
ENQ 
ETB 
ETX 
ITB 
STX 
SYN 


transmits the control code DLE in transparent mode 

forward abort, to denote end-of-transparent-mode 
end-of-transmission-block, to denote end-of-transparent-mode 
end-of-text, to denote end-of-transparent-mode 
end-of-intermediate-block, to denote end-of-transparent-mode 
Start-of-text, to denote start-of-transparent-mode 


synchronous idle. 


transparent mode is used when the transmission involves, 


binary data 


floating point numbers 


packed decimal data 


specialized or foreign codes 


computer programs in machine code. 


Heading data is control information used by the application for end-to-end con- 
trol related to the text data blocks following it. 


This control information which is separated from the text in the message, can on- 
ly be transmitted in normal mode, in one of the following ways, 


e embedded within the message containing any type of text, either normal or 
transparent 


o alone in a mesSSage, without text to follow it. 
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~ BSC2780 — 
continued 
GENERAL FORMAT OF DATA MESSAGES 


e The format of the data message for transmitting normal text is : 


e The format of the data tes eeee. for si iusicea: transparent text is : 


e The format of the data message for transmitting the heading is ;: 


see eo etna 
er moter eon 
seo sor sores se ceearne coeur 


BSC2780 
continued 


Explanation of Control Codes 


SYN 


STX 


SYN SYN SYN 

to establish and maintain synchronization 

The number of SYN control codes to be inserted by the URP is defined through 
the ININS parameter of the LINE command at network generation. 

The default number of SYN control codes is 4 


to denote that the character following is part of the transmitted text. 


n-text 


text transmitted in normal mode 


t-text 


oe 


ETB 


SOH 


text transmitted in transparent mode 


to denote the end of the block and to retain the direction of transmission. 
If the current block is correctly received, another block ended by ETB or ETX 
must follow. 


block cheek control used by URP firmware for checking or generating accumu- 
lated parity. 


used for temporizing between transmissions. 
The number of PAD control codes is defined through the PADNB parameter of the 
LINE command at network generation. 


to denote the end of transmission and to allow the reversal in the direction 
of transmission if EOT ending the last message was correctly received. 


to denote the end of the subblock and that more subblocks are to follow. 


data-link-escape used to provide 

e Supplementary line control codes in combination with other graphic symbols 
Example ;: DLE @ is interpreted as RVI (reverse-interrupt) 

« recognition of control functions specified in the transparent mode, see 
"Transparent Mode‘. 


to define the start of control information between 
e SOH and STX or ETB in normal mode 
e SOH and DLESTX in transparent mode. 
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-BSC2780 — 
continued 


Message Structure seen by BTNS 


A Secpmesdace exchanged between the BTNS message processing routines and the URP 
firmware can cone one of three pormaee, mame?ys 


e User-defined header message : | 


® sie weaee partitioned into blocks : 


[a [os [ees [To mm 


a optional —_ 


-) Transparent message text Ain which non-standard control estes are BECEDEES : 


“= optional —> 


STI | | 

- station index defined by the STATN command at network saneeselon: and set to 
1, see Network Generation Manual. 

TRI ; 

- terminal index, provision for multipoint handling 


SOH z a | | 
- to define the start of control information 


heading | 
- control information defined and provided by the user 


STX 


- to denote the start of transmission in normal mode, if not prefixed by DLE. 


- to denote the end of the block transmitted in yee eres if not prefixed by 
DLE, and to retain the direction of transmission | 


- to denote the end of transmission in normal mode, if not prefixed by DLE, and 
to allow the reversal in the direction of transmission _ 
DLE 


- to denote transmission in transparent mode, see accompanying codes. 
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BSC2780 
continued 


Message Structure seen by the Application 


The control codes shown in mark form are translated by the MCS stream processor 
into their corresponding hexadecimal values and transmitted over the line. 


e Format of header on emission and on reception in either mode ; 
[Te To [+] mene [> T<To Tos 
e Format of emission in normal mode ; 


e Format of emission in transparent mode : 


SHGHoREoHoC Ios 
Te [Te Te [senerer 


e Format of mesSage Structure on reception 3; 


CET Eps PEPP>. = 


- optional 


- to denote start of heading in the form of user-defined control information. 
- to denote end of heading, and the start of text transmission. 
- to denote that the text following is transmitted in transparent mode. 


- communication is "broken'', allowing reversal in the direction of transmission 
after sending the next end-of-file block terminated by ETX 


- communication is "kept", that is, retained, after sending the next end-of- 
file block terminated by ETX. 


text | 
- user-defined message shown as block transmission terminated by ETX. 


_ BSC2780_ 
continued» 


MANAGEMENT OF DATA TRANSFER BY THE APPLICATION 


Once the link has been established and set in the correct state to transmit data, 
_ the station whose turn it is to send data, retains its turn under the pOnnewene 
_ conditions, : 7 


- as long as it sends message blocks ceruinnees by [pLE]erB 


» until it sends a block terminated ey [DLEJETx, 4 in which case, Ene link state 
can be | 


- either retained in the message transfer state so that a new line bid is 
not necessary for resuming transmission in the same direction 


- or returned to the control state by sending EOT after the last block 


- unless RVI has been issued by the receiving station to request the reversal 
in the direction of transmission | 


Unlike other line procedures for which BINS manages the control codes, the user 
application, in the case of the BSC2780 line procedure, can control such func- 
tions affecting line usage through the MCS interface. 


Emission 
The user application can ‘control the turn cana the EMI and EGI delimiters of 
the [$H_ SEND. verb, as follows, © 


° amy mesSage sent with EMI is dispatched by BINS over the line with [pe]ers, 
3 cnereny retaining the turn > 


e any message sent with EGI is dispatched by BTNS over the line with (DLE]ETx, 
thereby signifying the end of the current transmission. 


Although the size of the physical block is determined by the buffering capacity 
of the receiving station, the user application is not concerned with this con- 
Straint since BINS automatically splits Be eeeees longer than the buffering capa- 
city by doing the following, “ | | 


- sending intermediate blocks of the message text with [puz] ers. 


» sending the last block with either [DLE]ETB or [DLE] ETX according to whether 
EMI or EGI was specified in the application. 


The physical block size is 512 characters, except in the case of the Level 61, 
which is restricted to 450 characters. . 


Reception 
Enqueuing of blocks depends on the control code terminating it, namely, 


-. a block received with [DLEJETB is “enqueued by BINS with EMI, ceereee setting 
the ENDKEY field of the input CD of the block to 2 


« a block received with [DLE] ETX is enqueued by BINS with EGI, thereby setting 
the ENDKEY field of the input CD of the block to 30 
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BSC2780 
continued 


For message processing on reception, see "Message Delimiters", pages 2-03 and 
2-04. 


Reverse Interrupt 


RVI provides the means by which the receiving station indicates to the sending 
Station that 


eo the last block sent with [DLE JETB has been correctly received 
« transmission must terminate aS soon as possible because 
- the receiving station cannot accept any more data 


~ the receiving station requires the turn to transmit a message of a higher 
priority than the message it is currently receiving. 


RECEIVING RVI 
The actions taken by BINS when it receives an RVI in the progress of current 
transmission are, 


» the next block is transmitted with [DLE ]ETX, whatever the delimiter of the 
corresponding message is, that is whether EMI or EGI 


e the corresponding terminal-queuve from which the block was sent is "disabled" 


2 the control message ><CTLRVI is sent to the program-queue to which the sta- 
tion is connected if the queue was declared with the BREAK option 


» the line is set to "input" to receive data from the requesting station. 
To detect RVI, the application needs to check the following status keys, 

e value "10", for a "disabled" terminal-queue 

« value "9B", for a null-length message as contents of the program-queue. 
When such an event is detected, the application must 


e either restart transmission by issuing [$H_JENABLE OUTPUT to the terminal- 
- queue if the status key value is "10" 


e and/or purge the terminal-queuve with the message ><CTLPRG with EGI. 


SENDING RVI 

“If the DPS 7 application receiving messages wants to stop the sending station, 

it sends the control message ><CTLRVI into the corresponding terminal-queue. 
After the reception of every block ending with DLE ETB, BINS performs as follows 


» checks the corresponding terminal-queue if RVI has been requested by the re-— 
ceiving application 


e if RVI has been requested, informs the sending station immediately. 
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 BSC2780 
. —. 


Retainin the Communication 7 


norma 1 sequence of events in eedneniesion is as follows, 


as a default option, BINS sends EOT after the last block of a ciunsese: Mayer 
cified with (DLE) ETxX : 


the link then returns to the control state 


the line, as a consequence must be bidden for, | in order for a new transfer 


to take place. 


In order to keep the link in the message Seaueeee State, the default aQyeaee by 
which BINS sends EOT, can be overridden. | 7 


If several transfers are to take place in the same dieackdon, the dapireneiss 


can 


specify that EOT must not be Seren eer ers sent by BINS by uSing the foll- 


owing control functions, 


- KCO is specified with the first block of a transfer in order to inform BTNS 


not to send EOT after the last blocks of the ears transfers until a new 
transfer is initiated with a "break" 


BCO is then specified with the first block of the last transfer in order to ; 
inform BINS that after the last block of the current transfer, it is to send | 
EOT in order to "break" connection and thereby allow the reversal of direct - 


ion in transmission. 
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BSC2780 
continued 


The sequence of transmission at the level of the file, where several files are 
concerned, is maintained for as long as the turn is kept. 


e The ist file is transferred with KCO be hoseimeaiee in the first block : 


Te Te Te] [esse mcccer ine fom] 
intermediate blocks } ETB 
last block of file 1 | 


e The 2nd file is transferred immediately after the ETX transmitted at the end 
of the 1st aad : 


first block | Sk 2nd se Bail 
| intermediate tpiiccke: 
| last neEees of as 1 | 


e All subsequent files are transmitted identically to the 2nd file. 


e The nth file is the last file to be transferred and therefore is specified with 
BCO in the first block ¢ 


BoogociIcrr Tce 
“intermediate blocks | ere | 
bese eee of cite nN. 


oe 


® EOT is sent only after the last file has been transferred, and until then, the 
link is still in the message transfer state. 
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7 continued _ 


CONTENTS OF USER MESSAGES 
The application as ean and/or receive heeding data alone or heading data foll- 
owed by the message text. 


In either case, the heading character string, limited to 15 SHAPERS is loca- _ 
ted at the start of the message in the following format. , 


The treatment of the message text depends on the mode of transmission. 


peeorme ner Text in Normal Mode 
There is no special format or processing for the text except for the Epeceee ae 
of standard marks, such as control codes in mark form, according to 

« the IM and OM options declared in the QUEUE command at network senevaeion 


. the options issued in the [$*$]MTE network control or terminal operator com-. 
mand during the communications session to override the IM and OM options, | 
respectively. — | 


See Section III, "MCS Data Formats". 


Treatment of Text in Transparent Mode 


The application receives transparent data in the same way as it receives normal 
data, except that no processing of standard marks is done, whatever the IM op- 
tion specified for the corresponding queue. 


To send in transparent mode, the user must ensure that the text of each message 
is preceded by ><U06, in which case, the following actions are taken, 


» MCS does not process standard marks 


« BINS provides the appropriate control pequence by prefixing control codes 
specified in the text by DLE. 


The BCS2780 line procedure supports the transmission of files in mixed normal 
and transparent modes. 


BSC2780 
continued 


Subblocks 
Messages are split into subblocks in order to provide a more efficient means of 
error checking. 


Retransmission of the subblock is at the level of [se line protocol and as such, 
is not visible to the application. 


BINS and the URP firmware ensure that the intermediate control codes separating 
the subblocks are handled as follows, for error detection and recovery, 


e checked for retries 
e inserted for emission 
« deleted on reception. 


The ability to use the subblock facility over a line is configured at URP firm- 
ware generation and is available in both normal and transparent modes of trans- 
mission. 


The format of the subblock separators depends on the mode of transmission. 


® ) subblock bis jatdaauilaale in normal mode : 


7 synchronization 


block check control 


intermediate transmission block 


e subblock separators in transparent mode : | 


Se entpeeeest OI  eem 
L restart | 
transparent mode 
synchronization 


block check control 


intermediate transmission block 


: BSC2780 
| continued 


Handling Se Text on Emission | 


- The esi lewis eonsideracions must be taken into account, 


« mesSage blocks are split into subblocks according to the SBKLG pavameter oe: 
- the appropriate TERMNL command, the default value being 80 


- the maximum number of subblocks for each message is 16 


« a line configured without the ‘subblock option at URP firmware generation 
cannot use this facility 


e even if the subblock option has been specified at URP firmware generation, 
the facility would not be of much use if the value defined for the SBKLG 
parameter is greater than any single block sent over the line because, in 
this case, only 1 subblock per block is defined. 


_@ Blocking of message text on emission : 


text of 190 characters | BESS eee Pele by 
| application 


mesSage sent by 
BINS and URP firm- 
ware over the line 


subblock 1 TT subblock 2 Ue subbisck 3 ETB/BIX 


| [a characters 
| subblock separators 
80 characters 
subblock separators 


80 characters 


Handling of Text on Reception 


All subblock separators are deleted and the subblocks are handled as contiguous 
data in the user buffer on [$H_]RECEIVE. 


The handling of text on reception is the reverse of that on emission. 
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TC 


The Olivetti TCV260 operates on the TC line procedure when linked to the DPS 7. 


Only general information concerning this terminal is treated. 


MESSAGE FORMAT AS SEEN BY BINS 


A message text exchanged between the BINS message processing routines and the 
URP firmware has the following format ; 


STI station index byte, that is, the station aCcEese as specified in the STATN 
command at CNC generation 


STX start-of-text 
RFE reserved for future extension, based on terminal cabling 


ADR address of auxiliary output device, that is, the "terminal-subtype", at- 
tached to the terminal 


ETB end-of-transmission-block 


EBCDIC 26, COBOL Collating Sequence 39 


ETX end-of-text 
EBCDIC 03, COBOL Collating Sequence 4 


The control codes, shown in mark form, ><ETB and ><ETX are used interchange- 
ably to indicate the termination of the message text. 


The characters are affixed automatically when the "transmit" key is pressed. 


“Some devices are equipped with ETB and ETX control keys, and when pressed, gen- 
erate the appropriate control codes. 
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continued © 
- ERASING FUNCTIONS 


Since the terminals are buffered, erasing functions are performed locally through 
available editing keys, such as "backspace", before the message is transmitted. 


TERMINAL SPECIFICS 


Refer to respective product manuals. 
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TTY 


The following terminals, known by their CNC declarations, operate on the TTY line 
procedure when linked to the DPS 7, 


e AJ832 ~. TN1200 e TTY33 e VIP7100 
« DTU7i71 e TTU8124 » TTY35 « VIP7200 
- OLIV318 o TTU8126 e TTY37 » VIP7802 
« TN300 | » TTY38 


These terminals using the TTY line procedure have limited functions in that they 
have no specific control codes. 


Communication is performed through a character-by-character mode over a point-to- 
point line with the DPS 7. 


Messages seen by BINS contain, 
e mesSage text 


e one trailer control code on input, in some cases. 


MESSAGE HANDLING ON INPUT 
On input, messages are terminated when any of the following control codes, shown 
in mark form, are received, namely, 


><CRV carriage-return, automatically suppressed by the URP firmware and not re- 
ceived by BINS 


><DC3 paper tape reader stop 
><EOT end-of-transmission, with the following considerations, 
« automatically suppressed by the URP firmware and not received by BINS 


» available only on terminals equipped with "reverse channel" option 
and connected over a 1200 bps line, namely, 


- DTU7171 
- TN1200 
- TTU8126 
-<LFV line feed 
><SUB substitute, automatically suppressed by the URP firmware and not received 
by BINS 
The following editing functions are, 


» graphic \ = ASCII 5C, used to erase the previous character of the message 
text, if the LINE connecting the terminal has been de- 
clared with the ERCAP option 


» graphic @ = ASCII 40, used before "carriage-return" in order to delete the 
complete line, and hence no message is delivered to the 
application | | 
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TTY 
| continued 


‘MESSAGE HANDLING ON OUTPUT 


On output, messages are terminated on exhaustion of the message length or are 
edited into fixed length lines, according to the following parameters declared 
in the QUEUE command , _ 


. LLENGTH 
» NBLOCKS © 
» BLOCKING. 


These parameter values can be altered during the communications session either 
by the network control operator or by the terminal operator, see Terminal Opera- 
tions Manual. | | : 


Other messages are edited by the application before they are submitted to BINS. 


ERROR HANDLING ~ 
A limited error recovery capability is possible with terminals using the TTY ae | 
procedure. . 3 


When the message "'RECV ERROR PLEASE REENTER'" appears on ‘he terminal, the oper- 
ator keys in the message text again 


Certain terminals replace invalid characters received from the host computer by 
a dedicated graphic symbol, e.ge, TTU8124 uses the graphic symbol 


Further recovery procedures must be supported by the application. 


VIP 


we 
7“ 


procedure when linked to the DPS 7, 


. BIT7300 . MTS7500 . TTU8221 . VIP7001 
. DKU7007 . MTS7508 . VIP765 . VIP7700 
. HL . STS2840 . VIP775 . VIP7760 


© KDS7255 / 7275 e TTS7800 e VIP785 e VIP7804 


MESSAGE FORMAT AS SEEN BY BINS 


A message text exchanged between the BINS message processing routines and the 
URP firmware has the following format ; | 


STI 


SOH 


ETB 


ETX 


EOT 


Station index byte, that is, the station address as specified in the STATN 
command at CNC generation 


start-of -~header 
EBCDIC 01, COBOL Collating Sequence 2 


terminal address as specified in the TERMNL command at CNC generation 


Status-code, used as follows, 
e STA=EBCDIC OO=NUL, for text only © 
» STA=EBCDIC 3F=PRT, for print message text 


function-code-1 
function-code-2 


Start-of-text 
EBCDIC 02, COBOL Collating Sequence 3 


end-of-transmission-block, only used for loading BIT7300 


EBCDIC 26, COBOL Collating Sequence 39 


end-of-text 
EBCDIC 03, COBOL Collating Sequence 4 


end-of-transmission 
EBCDIC 37, COBOL Collating Sequence 56 
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VIP a 8, 
continued — 


VIP HEADERS __ 


The header of each message sent to or ae vonva VIP terminal contains 3 bytes of in-| 


formation which may be useful to the MCS application. 

These 3 bytes are STA, FC1 and FC2. BINS has no effect on FCI and FC2, 
- consequence, both these function codes are unedited either on input or 

The URP firmware uses the TCT, terminal control table, for transcoding 


The VIP header is visible to the application when one of the following 
« the TERMNL command is specified with either IM=MK or IM=UN 


»« the network control command MTE specifying the terminal and either 
INEDT is issued 


ane aS a 
on outpute 
them. 


occurs, 


IMARK or 


. the terminal operator command $*$MTE specifying either IMARK or INEDT is” 


issued. 


The control codes received by the sapiueaeren when one of the above conditions is 


met, are of the format ><UO3abc, where 
e a represents STA, the status code 
« b represents FC1, function code 1 


e c¢ represents FC2, function code 2. 


The user can also include message headers of Bee same eounat in output messages 


in normal or unedited mode. 
See page 3- “37s for programming as ad of the ‘VIP header. 


VIP MESSAGE TRAILERS 


Terminals of the VIP line procedure use the sequence ><ETX><EOT to denote mes-_ 


Sage termination. 


* 


Some terminals are equipped with ETX and EOT neve which, when pressed, 
the appropriate control code. 


VIP ERASING FUNCTIONS 


generate 


VIP terminals are buffered. All editing sea erasing functions can be performed 


locally before entering a transmission request. 


Trailing blanks are suppressed from transmitted messages. Most VIP terminals do 


not transmit empty messages. 


When coding applications, the user should disregard empty messages. 
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SECTION VI 


PROGRAMMING TERMINALS 


The information concerns tz programming interface for terminals functioning with 
MCS applications, 


For details of transmission modes and program coding in MCS COBOL and GPL, see 
Section III, "MCS Data Formats" 


Control codes are shown in mark form, acceptable to MCS, for ease of recognition 
when listed in alphabetical order according to their mnemonic form, Where the con- 
trol code is not present in the list of control codes on page-3-03, its EBCDIC va- 
lue and corresponding graphic symbol, where applicable, are given, for example, 
the control codes CSI, DAQ and SGR for DKU7007 on page 6-06. 


Advice on program coding in this section, deal only with MCS COBOL, for example, 
SEND AFTER ADVANCING for MTS7500/7508 on page 6-26 and the mention of COBOL for 
LINE and PAGE for VIP7001 on page 6-45. In both these cases, the GPL equivalent 
is to be found on page 3-34 "AFTER ADVANCING PAGE". 


' Terminals are listed in order of their CNC names, that is, the name declared at 
network generation. 


* 


Each terminal is headed by the line procedure on which it operates. Transmission 
protocol implemented at system level is dealt with in Section V. 


For details of terminal performance specifications and special functional charac- 
teristics, such as the controller for DKU7007, consult the appropriate product 
manual. 


Programming Terminals in TDS : 


The rules for programming terminals in TDS are as follows, 


© Symbolic representation cannot be used in TDS, except for the VIP header 
><U03, which can be output to the VIP-type terminal, see page 3-02. 


© Tf the VIP "status" and "function codes" are to be passed to the transac- 
tion program, the corresponding TERMNL command for the VIP-type terminal 
must be declared with IM=UN, see Network Generation Manual. 


© Only the numeric form of the control code is acceptable, e.g., page 3-37, 
« for the COBOL TPR, the COBOL Collating Sequence as a decimal value 
o for the RPG transaction, the EBCDIC hexadecimal value within apostrophes | 
in the O-spec to the WORKSTN file, with the file-type in the F-spec | 
(col 15) specifying C for the "master" terminal. 
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Only common terminals are treated in this section. Terminals of the same line pro- 
cedure, having common characteristics can emulate each other. An example of this. 
emulation is the DKU7001 which functions equally as efficiently declared under 
DKU7001 as under VIP7200, as was the case in the previous release. | 
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AJ832 


AJ832 operates on TTY line procedure 


The AJ832 is a printer with the optional attachments, 
° paper tape unit 
e cassette handler. 

The keyboard can send any of the 128 ISO codes. 


The character set for the printer comprises 96 graphic symbols. The number in 
this character set excludes the "space" but includes the control codes FSV and 


GSV in the ISO graphic set, according to the type of printing wheel mounted on 
the printer. 


The product manual gives the graphic correspondence and equivalence between the 
various types of printing wheels. 


Characters received when a parity error occurs, are signalled as follows when 
the PAR CHK switch is on, 


° an acoustic signal is sounded 
© the appropriate character is printed with an * 


Line length depends on the model type and the PITCH switch The maximum line 
length, however, is 158 characters. 


CONTROL CODES 

The following terminal control codes in mark form apply to normal mode and as- 
sume ASCII graphics as well as the $*§NAPL/ $*$nap1 communications option, 
><BEL acoustic signal to the operator 

><BSV same line, one position to the left 

><CRV = reset print position to programmed left margin 

><ESCO (zero), reset to initial state 

><ESC1 set horizontal tabulation stop at current print position 

><ESC2 clear horizontal tabulation stop at current print position 
><ESC5 set vertical tabulation stop at current print line 

><ESC6 clear vertical tabulation stop at current print line 

- ><ESC7 backspace paper one line down, i-e., reverse line throw 

><ESC8 backspace paper half a line down, ieee, reverse half-line throw 
><ESC9 advance paper half a line up 

 ><ESC><BSV clear all horizontal tabulation stops 

><ESCD clear all vertical tabulation stops 


6-03 


(Ase32 
continued — 


CONTROL CODES (continued 


><ESCJ see ><SIV 

><ESCK see ><SOV | 7 a 

><ESCL set left margin at current print position 

_ ><ESCM : clear margins at positions 1 and 132 
><ESCN set to normal mode | | 
><ESCR set right margin at current print position 
><ESC= set right margin at current physical limit 
><FFV throw paper to top-of-page — 

><FSV- | 
><GSV _ | | 
><HTV. move print to next tabulation stop or end-of-line 


graphics according to the type of printing wheel 


><LFV advance paper one line up, switch selectable at 3 or 6 lines per inch 
><SIV stop printing —_ | 

><SOV resume print ing | 

><VTV = advance paper to next vertical tabulation Stop or. top-of -page 


Other Control Codes 


A number of control codes are available for, 
« page format control | 7 
« plotting of diagrams or drawing curves. 


Such codes are to be found in the product manua Le 
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DKU7007 


_DKU7007 operates on VIP line procedure 


DKU7007 DISPLAY/ KEYBOARD 


The screen is organized in 25 lines of 80 characters, the last line being reserv- 
ed for operator information. Including the "Space", 95 different graphic symbols, 
basically ISO/ASCII set with national options, can be displayed. An entry marker 
is displayed as an aid in formatting the screen. 


The FORMGEN utility is available for formatting the screen. The FORMRTP utility, 
the Forms run-time package, is then executed. 


Text for Display 


The control sequences for tabulation, entry marker control and message boundaries 
are the same as for the VIP7700, with functions additional to the VIP7760-2A, see 
"Define Area Qualification (DAQ)" and "Select Graphic Rendition (SGR)". 
Blinking and blanking are supported as options. 


FORMS MODE 

The following terminal control codes in mark form set the terminal either in 
forms mode or in normal mode. Forms are defined when in normal mode. 

><ESCM enters the terminal into forms mode 

_><ESCN resets the terminal into normal mode 


><FSV defines the start of a fixed field, must not be specified with DAQ com- 
mands 


><GSV._ defines the start of a variable field, followed by a value, as follows, 


O the field is right-justified, non-repeated and alphanumeric, to be 
transmitted and printed 


1 inhibits printing 
2 inhibits transmission 
4 numeric-only field 
8 indicates a number of a line field to be repeated 
16 the field is left-justified 
Must not be specified with DAQ commands. 
><RSV terminates a repetitive line field, followed by a repetition code 


‘value of repetition code : add 64 to the number of times that the line 
field is to be repeated, 7 4 
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~ DKU7007- 
continued 


Define Area Qualification _ 
DAQ commands can only be bezuea in normal mode. When issued in forms mode, the 
commands are ignored and no operation results. 


Format of command : (values are in EBCDIC, with corresponding evaphte ssabere) 


P=te.t=|:[|+ By: [= [= 


27 4A 5B SE SE 96 
><ESC [ ¢ ; : : g 9 


parameter parameter 7 parameter 


The following authorized parameters can be declared in any order and are in the 
sequence of EBCDIC values, shown with their corresponding graphic symbols, 
4c < field entirely filled in by the eae 


4CF3 <3 _ printable field 


6E > pure decimal numeric field, O through 9. 

7E = field that must be filled in by the operator — 

7EF1 =1 field filled in by the badge reader — 

FO QO variable and transmittable field, default parameter if none is speci- 

| fied in the DAQ command 

F1 1 fixed and non-transmittable field, petee the only authorized parameter 
for fixed fields | 

r3~ 3 decimal numeric field and computational operators, O through 9, +, -, 
> $ | | : 


F5 5 right-justified field. 


Select Graphic Rendition 
SGR commands can be issued in forms as well as normal mode. 


Format of command : (values are in EBCDIC, with corresponding graphic symbols) 


rete [n|[:]=|+ Me: [= [= 


27 4A SE 5E 5SE | 94 
><esc [ ¢ ; ; es m 


parameter parameter | parameter 


The SGR command occupies a one "spice"! position on the screen, hence the entry 
marker moves forward by one position on <empletion of the command. 


The number of SGR, blink and blank commands is limited to 15 per line. — 
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DKU7007 
continued 


The following authorized parameters can be declared in any order in the SGR com- 
mand and are in the sequence of EBCDIC values, shown with their graphic symbols, 


FO O- normal intensity, default parameter if none is specified in the SGR 


command 
F2 2 #£+half intensity 
F4 4 underlined by a continuous line 
F> 5 blinking 
F7 7 reverse video 
F8 8 security. 


DKU7007 PRINTER 


The printer must be defined by a separate TERMNL command declaring the "terminal- 
subtype" as PRT at CNC generation. Text for printing can only be sent to the 
printer address, 


The three printing modes are treated as follows, 
« transparent mode 
» display image mode 
. forms mode. 
In forms and display image modes, printer control functions and "time- fills" are 
automatically generated by the controller. 
In transparent mode, however, the user must ensure that the "time-fill" count is 
adequate for proper printer synchronization. 
| To define the "time-fill" count in transparent mode, proceed as follows, 
| » Determine the value to be given for the number of "time-fills", say, 6 
- Start from ASCII code 20 which is a "space", using the ASCII table 
- Count 6 codes from ASCII code 20 inclusive 
- The ASCII code arrived at is 25 
~ The EBCDIC equivalent is 6C or graphic % 


e In the MCS application, send a control sequence in one of the formats : 


| ><uSV% using the graphic symbol | _ 


><USV><C6C using the EBCDIC value in control character form 
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~ DKU7007 
- continued 
_DKU7007 PRINTER (continued) 


Transparent Mode 


Method of addressing is as follows, | | | 
- either address the printer with STA=3F in the VIP header 
-. or address the printer | | 
- with STA=00 in the VIP header 
« and, precede the text with ><ESCZ. 


The message is printed as it is. The text in the message must contain all the ne- 
cesSary control codes specific to the printer and for formatting the text, see 
"Text for Display". 


"Time- fi1i" control codes for the proper mechanical synchronization of the print- 
er should also be included in the message text. 


><uSV. defines the "time-fill" count, in the case where the printer is ‘oak for 
| hard copy, and where the proper synchronization of the printer mechanism 
is required, see the previous page for programming the "time-fills'. 


Display Image Mode 
Method of addressing is as follows, 
- address the printer with STA=00 in the VIP header 
- and, terminate the message text with ><ESCN. 
The message text may optionally begin with ><ESCX or ><ESCY. 


The text is formatted automatically on the printer according to the diepiay char- 
acteristics of the format. | | 


Printer control functions and "time-fills" are automatically generated by the 
controller. | 


Forms Mode 


Method of addressing is as follows, 

- address the printer with STA=00O in the VIP header 

. and, terminate the message text with ><ESCM. 
If the text begins with ><ESCX, only the variable fields will be printed. 
If the text begins with ><ESCY, both fixed and variable fields will be printed. 
If the text is not preceded by ><ESCX or ><ESCY, it will not be printed. 
Variable fields defined as "inhibit-printing" will not be printed. 


The controller automatically generates printer control functions and "time-fills". 
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DTU7171 


DTU7171 operates on TTY line procedure 


The display terminal unit is equipped with a keyboard and display screen. 


The screen buffer size is organized as follows, 
» 480 characters composed of 12 lines of 40 double sized characters 
- 960 characters composed of 12 lines of 80 characters 
e 1920 characters composed of 24 lines of 80 characters 


Depending on an operator activated switch on the terminal, excess characters can 
either be overprinted on the last line or "rolled-up". 


The character set contains 64 different graphic symbols or 95, if the lower case 
option is present. The types of graphic symbols are determined by the national 
options available. 


A printer for hard copy can be attached to the terminal and is controlled by de- 
vice function codes sent to the DTU7171 in output messages addressed to it. 


DTU7171 DISPLAY 


The information listed is a summary description and does not explain behavior 
near the screen boundaries. 


The current entry position is marked by the position of the cursor. 


>< ACK 
>< B03 
>< BSV 
>< BEL 
><CAN 
><CRV 
><DC2 
><DC4 
>< EMV 
><GsV 
>< HTV 
>< LFV 
><NLV 
—><RSV 
>< SUB 
><usvV 
><VTV 


position the cursor according to character position and line number 


next line, first character position 


same line, one position to the left 

acoustic signal to the operator 

same line, next character position 

same line, first character position 

turn on cursor and enable/resume printing 

turn off cursor and suppress printing 

same as ><BSV 

first line, first character position, top left or "home"! 

same as ><B03 

next line, same character position 

same as ><BO3 | | 

erase all characters from cursor position to the end of the line 
previous line, same character position 

erase all characters from cursor position to the end of screen 
Same as ><LFV | | 
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—ptu7i71— 
continued 


To position the cursor, proceed as follows using the ASCII table 

. Determine the value to be given for the character position, say, 37 
- Start from ASCII code 20 which is a "space" 
- Count 37 codes from ASCII code 20 inclusive 

+ The ASCII code arrived at is 44 

- The EBCDIC equivalent is C4 or graphic D 

- Determine the value to be given to the line number, say, 11 
- Use exactly the same method as above for character position 
- The EBCDIC equivalent is 5C or graphic * 


« In the MCS application, send a control sequence in one of the formats : 


><ACKD* using graphic symbols 


>< ACK ><CC4><C5C using EBCDIC values in control character form | 


DTU7171 PRINTER ATTACHMENT 


To resume printing, the cursor must be restored in one of two ways, 


» by activating the CTR and R control keys, this action being done by the op- 
erator | : | 


‘s by sending the control code ><DC2, this action being done by the applica- 
tion. | | 


The other control codes applicable to printer operations are, 
><pDC4 turn off cursor and suppress printing 
><DLE start simultaneous printing and display 


><ETB print contents of screen 


IBM3270 


| "1BM3270 operates on BSC3270 line procedure 


: 


The IBM3270 identifies the following components, 
e 3271 Model 2 control unit in general poll mode 
e 3277 Model 2 display station 
o 3284 Model 2 printer. 


The control unit has a 1920-character buffer capacity and can be configured with 
up to 32 display stations and printers. 
At least 1 display station is needed for the control unite 


The display station comprises a screen with keyboard, capable of displaying 1920 
characters per screen in 24 rows of 80 characters. 

The screen can display the 64 standard ASCII characters. 

The cursor indicates where the next character will appear on the Screen and is 
represented by an underscore (_). 


The printer has a 1920-character buffer, a 40-cps print rate and allows a choice 
of 120, 126 or 132 print positions per line. uo eG eae 
The displayable characters on the Screen can be reproduced as hard copy on the 
printer. 


CNC DECLARATION 
All display stations and printers configured to the same control unit are de- 
clared by individual TERMNL commands under one STATN command, as follows, 

» each display station is declared as IBM3270 with the terminal-subtype KCT 


« the printer aSsociated with the display station immediately follows it and is 
declared as SLAVE with the terminal-subtype PRT 


e the parameter ADD is mandatory for each TERMNL command declared, introducing 
values which are determined at the time of installation and are obtainable 
from the Field Engineering Service. 7 


Associated with each TERMNL command is a QUEUE command in which the unedited mode 
is mandatorily declared as follows, 


e for the terminal-subtype KCT, IM=UN;, OM=UN 
« for the terminal-subtype PRT, OM=UN. 


In unedited mode, symbolic representation must not be used, see page 3-02. 


TDS ENVIRONMENT 


The Forms utility, comprising FORMGEN and FORMRTP, is used to format the Screen, 


-1BM3270 

continued 

COMMANDS : formats give ‘EBCDIC values and, where applicable, the equivalent gra- | 
phic symbol | 


e Write / Erase and Write : referred to in the text as "write" operations | 


see "Orders!'; | 
this byte can also be apes for 
the start of data, consult the 


ice f dats, 
NEES EMER character set available 


character | | 
—— see "Processing on Output", 
erase and write 


FS 7 page 3-18 
5 . see "Output Normal Mode", 
page 3- 21 


Programming points to observe, 

-. if commands are chained, "write" operations with the "start petntee bit 
set, must be the last in the chain | | | 

« the printout format bits are honored only if the "start printer" bit is set 
in the same WCC | - 

- if a "write" operation includes data chained from a previous "write" opera- 
tion, an SBA order must immediately follow the WCC to define the "start" 
address at which data entry is to commence. 


Write Control Character 
for decoding, see "I/O Codes" 


Explanation 


2-3 | printout format, defined as follows, 
= 00 , NL and EM control codes in the data stream determine print line 
length; provides a | 132-print position line when no control codes 
are present 
O1 , specifies a 40-character print line 
10 , specifies a 64-character print line 
11 , specifies an 80-character print line 


Start printer : when set to 1, initiates a printout operation on comp le- 
tion of a "write" operation 


sound alarm: when set to 1, sounds an audible alarm at the selected de- 
vice at the end of an operation 


keyboard restore : when set to 1, restores the functioning of the key- 
board by resetting the INPUT INHIBITED on the screen; also resets the 
| AID byte on termination of an I/O command 


‘reset MDT : when set to 1, all MDTs in the data Poueaiued in the buffer 
of the selected device are reset before any further data is written or 
any Oreche: executed 
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IBM3270 
continued 


COMMANDS (continued) » 


@ Copy 


es £2 copy | oc | "sender" = 


kA mh d; 
"from'' device address 


copy control character 


Programming points to observe, 
e "Copy'' should not be chained from a 'write" operation 
» If the "start printer" bit is set and commands are being chained, "copy" must 
be the last in the chain 
» Once the data stream has been sent to the printer, the user program should 
send the following data stream to the display station that requested the copy, 
MBEKEPY: ene WCC in the data stream is to restore the keyboard : 


Copy Control Character 


for decoding, see "I/O Codes" 


ae Explanation | | 
2-3 | printout format, defined as follows, 
= 00 , NL and EM control codes in the data stream determine print line 


length; provides a 132-print position line when no control codes 
are present 

specifies a 40-character print line 

specifies a 64-character print line 

specifies an 80-character print line 


Start printer : when set to 1, initiates a printout operation at the © 
"receiver'' printer once buffer transfers are completed | 


sound alarm : when set to 1, sounds an audible alarm at the selected 
"receiver" device once buffer transfers are completed 


| data type, defined for copying as follows, 


= O00, 


10 , 


11, 


only attributes are to be copied 

attributes and unprotected alphanumeric fields are to be copied; 
protected fields are substituted for "null's" 

attributes and protected alphanumeric fields are to be copied; 
unprotected fields are substituted for "null's" 

entire contents of the storage buffer are to be copied 


1BM3270_ 
continued © 


COMMANDS ae 
e Erase All Unprotected data 
EBCDIC 6F, Graphic Symbol ? 


The EAU command performs 5 functions at the addressed device, 
« clears all unprotected character locations to "null's" 
» resets the MDT bit for each unprotected field to zero, see WCC of "write" 
« unlocks the keyboard attached to the display 
e resets the AID byte, see AID of "read modified" 
« reposSitions the cursor to the ist character location in the 1st unprotected 
field of the buffer; if no unprotected fields exist, the cursor is posi- 
tioned to buffer location 0. 7 


The EAU command should not be chained to a 'write!' o eration or to a "copy"! 
command. | , 


e Read Modified 
The "read modified" command is executed during the general polling sequences 


The format of the "read" data stream is as follows, 


Nread" read" heading ist modi fied field | 7 | nth modified field 


ee nt | oe 


ad are buffer address of 1st 
character position in 
first modified field 
(attribute address +1) 


"set buffer address", see "Orders" 


cursor address 


attention identification 


In the "read'' heading, the AID byte, being the ist byte in the data stream, 
identifies the function key activated at the keyboard by the operator. The user 
program can test the value of the AID code, and accordingly can perform the 
type of intervention required. 


Successive modified fields follow on after the "read" heading. 

As a field is modified by the operator, the MDT bit is set in the "attribute" 
byte for that field. Successive "attributes" are scanned for the set MDT bit, 
and when found, the data in the corresponding field is read, with "null's" 
suppressed, before the next "attribute'' is examined. 


The SBA order code serves as a delimiter for the end of data of the preceding 
field and the start of the buffer address of the field following. 


If no fields have been modified, only the "read" heading will appear. 
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IBM3270 
continued 


COMMANDS (continued) 


e Read Modified (continued) 


"Short'! read denotes that no modified fields follow. 


Attention Identification 


Gpgroup resultant transfer EB=EBCDIC value GrS =graphic symbol 


modified 

modified | 
modified | 
modified | 


no AID generated 


_— 
|(display station) 


no AID generated 


| (printer) jmonteted 


‘ENTER and & 
selector pen 
attention 


| modified 


modified 
Imodified | 


|modified 
|modified | 
imodified | 
imodified 


selector pen 
jattention 
‘space null — 


|modified | 


| 7E imodified | 


SA © COU AUW EWA 


|modified 


¢ field addresses and text in modified fields are transferred 


the AID code,.cursor address, SBA order, attribute address+ 1 and text 
for each modified field are transferred; 
“nulls are suppressed | 

C : the AID code, cursor address and field addresses are transferred}; 

- no data is transferred 


only the AID code is transferred 


- 1BM3270 
continued 


DEVICE ADDRESSES 
| Device addresses used in the "copy" command are hardware EonengUres and are de- 
_ termined at the time of installation. : 


These values, like those of the ADD parameter declared at network generation, are 
obtainable from the Field Engineering Service. 


The "to'' device identifies the "receiver" while the "from" device identifies the 
"sender". 


I/O CODES 
| 1/0 codes represent the decoding « of bits set by the user in the following parame: 
ters, | 
» WCC, write coubeol character of "write" operations 
° ccc, copy control character of the ''copy' command 
° "attribute" of the Pr ehee field order. 
Bits O and 1 are omitted, since their values are not defined by the user but are 


instead reserved for use by the IBM3270.. 
Their settings do not affect the ete of the Ene to be specified. 


1/0 Codes 


| 2 through 7 denote bits set by user 3 GrS = graphic BymbOns EB lak coshea a value 


23 4567. roe 23 O07 Go 23 4567 pee E 23 43567 


O1 0000 
01 0001 
01 0010. 
O01 0011 


#O1 0100 
O01 0101 
O01 0110 
O01 0111 


#01 1000 
O01 1001 
O01 1010 
O1 1011 


#01 1100 
Oil 1101 
O01 1110 

O1 1111 


Hm AamMtMmod AOw > dq 
--"-NK NES AMW™! 


ro 
-- 
| a | 


“Vt @ DO VOZER MAUe 


il ~® The OO URDU WNHO 


+AA 
ee 


ee 


> 
J 
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IBM3270 
continued 


: formats give EBCDIC values 


Insert Cursor ; 
repositions the cursor to the location specified by the current buffer 
address. 


EBCDIC 13 


Program Tabulation ; 
advances the current buffer address to the address of the ist character 
position of the next unprotected field. 


EBCDIC 05 


Start Field ; 
notifies the control unit that the next byte is an attribute in the 
"write"! anes Stream to be stored at the current buffer address. 


Jattribute| 


1D 


Start Field Attribute 
for decoding, see "I/O Codes" 


| Explanation 


ie =unprotected 


1 = protected 


O=alphanumeric 
1=numeric only, causes automatic upper-case shift in data enery key- 
board 


| 00=display / not selector-pen detectable 
_| Ol=display / selector-pen detectable 


10=intensified display / selector-pen detectable 
11=nondisplay, nonprint, not selector-pen detectable 


| must be zero 


| MDT (modified data tag) : identifies modified fields during "read modi- 
| fied" commands, as follows, | 
| O=field has not been modified | 
| 1=field has been modified by the epereeces can also be set by the appli-] 
cation in the data streams | : 


- 1BM3270 © 
continued 


ORDERS (continued) 
® ‘SBA - Set Buffer Addrees : 
specifies a new buffer address from which "write" operations are to Start 


or continue; can precede all other orders in the data stream to indicate 
various areas of the buffer. 


11 


Llidaasid address, see "Cursor Positioning" 


@ RA - Repeat to Address : 
| Stores a specified character repetitively starting at ‘the current buffer 
address and ending, but not including, the specified "stop" address. 


k 


—— see "Cursor Positioning" 


e EUA - Erase Unprotected to Address : 
inserts "null's" in all unprotected buffer locations, starting at the 
current buffer address and ending, but not including, the specified 
"stop" address; attributes remain unaffected. 


' 


12 


‘thee address, see "Cursor Positioning" 


To position the cursor, proceed as follows using the "Cursor Positioning" 
table opposite 


- Determine the co-ordinates of the cursor, say row 7, column 64 


e« Row 7 has the EBCDIC value C7 only up to column 323; between columns 33 
and 80, row 7 has the value C8. 
Since the column re uired is 64, the value for row 7 is therefore C8. 


Column 64 lies in the range between columns 59 and 66, with the corres- 
ite consecutive EBCDIC values ranging from 5A through 61. | 


By pairing the columns with their eguceapondine EBCDIC values, the value 
for column 64 Shown unshaded is 5F. 


« The buffer address of the cursor at row 7, column 64 is "C8'"5Fn, 
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Cursor Positioning 
for 3277 Model 2 Display Station 


R, C denote "row' and "column" respectively of the cursor, being the co-ordinates to reference the curser. 
R, C are the corresponding EBCDIC values for R, C respectively. 


Intervening columns are omitted if their corresponding EBCDIC values are consecutive within a given range. 
Rows are not repeated if their values remain unchanged from the initial value fur a given range in the row. 


1BM3270— 
continued 
TERMINAL SPECIFICS 


Refer to the appropriate product manual. 


KDS7255, 7275 


KDS7255 and KDS7275 operate on VIP line Procedure 


The KDS7255 identifies the KDS7255/7256, while the KDS7275 identifies both the 
KDS7265/7266 and the KDS7275/7276. 


From the point of view of programming and operation, all versions of KDS confi- 
gured on the DPS 7 are identical. 


The KDS is a data-capture system operating in the following sequence, 
» data is entered on the keyboard, and is checked and formatted locally 
- it is then transcribed onto the diskette 
e once the KDS is connected to the DPS 7, the data on the diskette is avail- 


able for deferred transfer. 


The visibility from the application is limited to a receive-only display and two 
diskette units. 


KDS DISPLAY 
The KDS display must be declared at network generation by a separate TERMNL com- 
mand specifying the following mandatory parameters, 

» CRT as the "terminal-subtype" _ 

- ASSIGN, specifying either an input-queue as a "dummy" assignment or TDS 

» AUTO, for logon to be performed by the communications software, since the KDS 


keyboard is not interactive. 


The network control operator can modify the assignment during the communications 
session. 


The screen is organized in 4 lines of 32 characters. Including the "space", 64 
different graphic symbols can be displayed. 

Display is limited to the first 128 characters of each message texte 

Page overflow occurs when a message text exceeds 960 characters. 


The only control code for managing the screen is ><FFV which serves to reset the 
screen before the message is displayed. 7 


- KDS7255, 7275 
continued 


| KDS DISKETTE UNIT 
The KDS diskette unit must be declared at network seieracin ey a gecarare 
TERMNL command specifying DSK as the "terminal- -subtype'. 


Messages with STA=OO in the VIP header can be exchanged between the sep lteacton 
and the unit. , | —— 


The characteristics of the data are, | 
. maximum size of the message is 960 characters, being the page size 


- the size of the records on the diskette is determined by the diskette label, 
however, the presence of ><CRV or ><CRV><LFV in a message sent to the 
diskette uni forces an end to the current record and data following it be-- 
gins a new record. 7 


The following control code sequences in mark form enable the operational hand- 
ling of the diskette unit, 

><EOF end-of-file, with no characters following to close the file 
><ESCE><ESCR read data from diskette unit 1 - 

><ESCF><ESCR read data from diskette unit 2 

><ESCE ><ESCS followed by data, write data to diskette unit 1 

><ESCE ><ESCS ><FFVY><DELEOF end-of-file to be written to diskette unit 1 
><ESCF><ESCS followed by data, write data to diskette unit 2 
><ESCF><ESCS><FFV><DELEOF  end-of-file to be written to diskette unit 2 


TERMINAL SPECIFICS 


Refer to respective product manuals. 
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MTS7500, 7508 


The MTS7500 and MTS7508 are miltifunction terminal systems equipped with, 
¢ a programmable processor with central memory 
e a keyboard and a disr'ay screen with full ISO capability 
« auxiliary terminals, such as, 
- diskette subsystem 
- printer. 


The difference between the MTS7500 and the MTS7508 is that only the MTS7500 can 
be configured with a cassette unit comprising two cassette handlers. 

The visibility of the multifunction terminal systems to the host is that of a 
VIP7700 with a printer and with 


- either a diskette system, in the case of both MTS7500 and MTS7508 
» or two cassette handlers, in the case of MTS7500. 


MTS7500/ 7508 DISPLAY/ KEYBOARD 


The screen is organized in 12 lines of 80 characters. Including the "space", 95 
different graphic symbols, comprising both upper and lower case, can be display- 
ed. 


A cursor is displayed as an aid in formatting the screen. 


Local software controls the data format. 


Header for Display/ Keyboard 


The 3 parameters in the VIP header have the following values, 


« STA=EBCDIC OO=COBOL Collating Sequence 1 
» FCi=last function code entered on the keyboard or echo to the application 
e FC2=last but one function code entered or echo to the application. 


Text _for Display 


ENTRY MARKER 3: 

The following terminal control codes in mark form alter the current entry po- 
sition, | 

><BO1 as for ><DC4, with display memory cleared, i.e., screen erased 

><BO3 equivalent to the sequence ><CRV><LFV 

><BSV same line, 1 character position to the left — 

><CRV same line, leftmost character position : 


><DC1 one line up, same character position, ieee, reverse line feed 
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MTS7500, 7508 
continued =} 


ENTRY MARKER (continued) : | 


><DC2 same line, 1 character position to the right, i.e., forward space 
><DC3 position cursor according to line number and character position © 
><DC4 uppermost line, leftmost character position, ises, page return — 
><DEL follows ><HTV, ><FFV, ><BO1 as a "time-fill" 

D<FFV same as ><BOL | 

><HTV same line, first tabulation to the right 

><LFV one line down, same character position 

><NLV same as ><BO3 


To position the cursor, proceed as follows using the ASCII table 

_« Determine the value to be given for the line number, say, 11 
- Start from ASCII code 20 which is a "space" 
+ Count 11 codes from ASCII code 20 inclusive 
- The ASCII code arrived at is 2A 
: The EBCDIC equivalent is 5C or graphic * 

« Determine the value to be given for the character position, Say, 37 

| - Use exactly the same method as above for the line number 

- The EBCDIC equivalent is C4 or graphic D | 


-« In the MCS application, send a control sequence in one of the formats : 


><DC3*D using graphic symbols 


><DC3 ><Cc5C><CC4 using EBCDIC values in control character form 
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MTS7500, 7508 
continued 


PAGE OVERFLOW : 


detection 


a message OVERFLOW is displayed on the screen, if an attempt is made to send 
data greater than either 12 lines or 960 data characters. 


' cause 

o result of a programming error 

e result of an operator error in failing to clear the screen 
correction 


e press KEYBOARD control key and H simultaneously 
e send the command $*$RDY 


e if overflow occurs again as a result of message length, send the command 
$*$RDY STRONG to cancel the message. 


The following functions for text for display are not supported, namely, 
e blanking - 


o blinking 
e forms mode 


e tabulation 
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‘MTS7500, 7508 
_ continued 


MTS7500/7508 DISKETTE UNIT — 


The diskette unit must be defined by a separate TERMNL command declaring the 
"terminal-subtype" as DSK at CNC generation. 


_ Mes 


sages with STA=00_ in the VIP header can be exchanged between the epplication 


_ and the diskette unite 


The 


characteristics of the data are, 


maximum size of block is 960 characters, ieee, a maximum of 984 characters 
in 12 lines of 80 data characters plus the control codes CRVLEV 


maximum size of record is 249 characters, including the mandatory end-of- 
record control sequence ><CRV><LFV 


maximum size of last record in a block is 248 characters, including the man- 
datory end-of-block control sequence ><CRV 


with the LOW SPEED options. data can out be received by the host processor 
as separate records 


with the HIGH SPEED option, only complete files can be read from or written 
to the diskette unit. ee 


The control sequences for a diskette unit are, 


><EOF end-of-file, with no characters following to close the file 


><ESCR "read'' command, issued once in the message to the diskette unit 
><ESCS "write" command, followed by a block of records 


To generate end-of-record control codes, do NOT use either COBOL facility, 


e SEND AFTER ADVANCING clause 
« BLOCKING option. 


Either method will generate the control sequence ><CRV><LFV in front of 


the record, thus making it an me first record which is not acceptable to 
the MTS7500/ 7508. 7 


When reading from the diskette unit, EOF denotes that the end-of-file has 
been reached. 


When writing to the diskette unit, EOF followed by either ><cRV><LFV or 


| ><cRV is considered a normal record. 
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MTS7500, 7508 
continued 

MTS7500 CASSETTE UNIT 
The MTS7500 cassette unit must be defined by a separate TERMNL command declaring 


the "terminal-subtype" as CAS at CNC generation. 


Messages with STA=00 in the VIP header can be exchanged between the application 
and the cassette unit. 


The characteristics of the data for the MTS7500 cassette unit are the Same as 
those which apply to the MTS7500 diskette unite 


Messages sent to the cassette unit must contain the following information, in 
the sequence as shown, 


« selection of the cassette unit, whether front or rear 
» type of command 


e message text, where applicable. 
SELECTION : 
The following terminal control codes in mark form enable the selection of the ~~ 
cassette unit, in the sequence shown, 


><ESCE selects the rear cassette handler , followed by . ><ESCX 


><ESCF selects the front cassette handler, followed by ><ESCX 
-><ESCX empty text 


COMMAND ; 
The following terminal control codes in mark form enable the operation of the 
cassette handler selected, 


><ESCP rewind to the start of cassette tape, followed by ><ESCX 


><ESCR "read"! command, issued once in the message to the cassette handler 
_><ESCS "write" command, followed by a block of records 


The "backspace" function ><ESCD is not Supported and must not be sent. 


The MTS7500 disconnects the line when the control sequence ><ESCD is — 
issued. 


d 6-27 


MTS7500, 7508 
continued = 


MTS7500/7508 PRINTER 


Printable text is defined between the control codes in mark form ><STX, to de- 


note "start-of-text" and, either ><ETX or ><EMV, to denote "end-of-text". 


Text output to the printer does not appear on the screen. 


© Method of addressing (1) : 


° address the display/keyboard with STA=00 in the VIP header. — 
The keyboard is locked during printing. — 


The message is printed as it is. The text in the message must contain all nec- 


essary control codes for formatting the text, which are the same as for posi- | 


tioning the entry marker for display on the Screen. 


Like display on the screen, "time-fills" are required to enSure proper Syn- 
chronization of the printer mechanism Any control code which causes movement 
of the printer mechanism, such as "carriage-return" and "line-feed", must be 
immediately followed by a sequence of "time-fills", ><DEL, before any text is 
sent to be oo Full line size capability is obtained by this method. | 


Method of addressing (2): 


° define the printer by a separate TERMNL command declaring the ''terminal- 
_ subtype as PRT at CNC generation 
- address the display/keyboard with STA=00 in the VIP header. 


The keyboard is not locked and may be used to enter data into the screen and 
to transmit the data while printing proceeds. 


"Time-fills'' may be needed to ensure proper synchronization of the printer. 


Full line size capability is obtained by this method. 


© Method of addressing (3) : 


e define the printer by a separate TERMNL command declaring the "terminal- 
subtype" as PRT at CNC generation 
« address the display/keyboard with STA=3F in the VIP header. 


The keyboard is not locked and may be used to enter data into the screen and 
to transmit the data while printing proceeds. 


The message is printed as it is. The text in the mesSage must contain all nec- 
esSary control codes for formatting the text, which are the Same as for posi- 
tioning the entry marker for display on the screen. 


Like display on the screen, "time-fills" are required to ensure proper syn- 
chronization of the printer mechanism Any control code which causes movement 
of the printer mechanism, such as "'carriage-return" and "line-feed", must be 


immediately followed by a sequence of "time-fills", ><DEL, before any text is 


sent to be printed. Full line size capability is obtained by this method. 


STS2840 


| STS2840 operates on VIP line procedure | 


STS2840 is a generic name for a cluster of stations seen as a multipoint VIP 


line. 


Each STS2840 station can contain up to 3 terminals, namely, 


» a display with keyboard 


e a printer 


» a diskette unite 


STS2840 DISPLAY/ KEYBOARD 


The screen is organized in 16 or 24 lines of 80 character positions. 


96 different graphic symbols can be displayed, their types depending on nation- 
al options. | 


A marker line is displayed as an aid in formatting the screen. 


Text for Display 


The following terminal control codes in mark form enable the operational hand- 
ling of the display, 


><CRV><LFV or ><LFV, see ><ESCS 


><ESCA 
><ESCC 
><ESCD 
><ESCG 
><ESCH 
><ESCI 


><ESCJ . 


><ESCK 
><ESCL 
_><ESCN 
><ESCO 
><ESCQ 
><ESCS 
><ESCT 


resume expanded message format 

Start companion hard copy on the printer 

request “send | | 
acoustic signal to the operator and display "ALARME 31" 
move cursor one position to the left on the same line 


move cursor to the next tabulation stop on the right 


erase end-of-line, and move cursor to the next line at first character 


position | 
move cursor one line down at the same character position 


move cursor to the first line at first character position 


Start of protected field 


Start of unprotected field 
move cursor one line up at the same character position 
move cursor to the next line at first character position 


access protected area 
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* 


— STs2840 


><ESCW erase end-of-line and any subsequent teers | 
><ESCX. clear screen, and reset cursor in "home" position, ives, at leftmost 
| character position at sche top of the screen 
><ESCY erase field | | | | | | oe 
><ESC) call "screen-format" from companion diskette, the 4 characters identi- 


><ESC@ 
><ESC \ 


><esc ] 


><ESC* 

><ESC_ 
><DC1 
 ><pc2 

 ><pe4 
_ ><FFV 
><GsV 


_ fying the name of the "screen-format" must follow on immediately. 


This control sequence must form a complete message in itself. 

start compressed message format 

display graphic symbol = 

display one blank 

subfield delimiter. | 

move cursor one position to the right on the Same Wve 

request screen dump | 

position the cursor according to line number and character position 
position the cursor after osprey. of the current message is completed 
see ><ESCX 


field delimiter, followed by an attribute character pOSRESEYEDS the 
field | 


To position the cursor, proceed as follows using the ASCII table 


« Determine the value to be given for the line number, say, 11 


- Start from ASCII code 20 which is a "space" 
- Count 11 codes from ASCII code 20. inclusive 
- The ASCII code arrived at is 2A 

- The EBCDIC equivalent is 5C or graphic * 


° Determine the value to be given _for the character position, say, 37 


- Use exactly the same method as above for the line number 


- The EBCDIC equivalent is C4 or graphic D | 


« In the MCS application, send a control sequence in one of the formats : 


we 
ae 


><DG2*D using graphic symbols 


><DC2 ><C5C><CC4 using EBCDIC values in control character form 
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TNS30OO, 1200 


‘TN300/1200 operate on TTY line procedure 


. The TN300 and TN1i200 are printers with the options, | 
e keyboard 
0 paper tape attachment 
o cassette. 

The keyboard can send any of the 128 ISO codes. 


The character set for the printer comprises 94 graphic symbols (excluding the 
"space") according to the national options available. 


Characters received with parity error are treated as follows, 

e if TN300, an "interrupt" condition is set up at the terminal 

» if TN1200, the erroneous character is printed with the graphic symbol ©. 
Line length depends on the model and the options available, namely, 

© if TN300, 118 character positions 

» if TN1200, either 80 or 120 character positions. 


CONTROL CODES 


Unless specifically stated, the control codes in mark form pertain to both TN300 
and TN1200. 

><BEL sounds an alarm 

><BSV moves print one position to the left | 
><CRV resets print position to first tabulation stop or leftmost column 
><DCi starts paper tape reader forwards, optionally used for cassette 
><DC2 starts paper tape punch, optionally used for cassette 

><DC3 stops paper tape reader, optionally used for cassette 

><DC4 stops paper tape punch, optionally used for cassette 

><ESCO starts paper tape reader backwards, optionally used for cassette 
-<ESC1 sets horizontal tabulation Stop at current print position 

><ESC2 clears all tabulation stops 

><ESC3 applicable only for TN1200, selects red printing option 

><ESC4 applicable only for TN1200, selects black printing option 

><ESCH turns on printer motor | 


><ESCJ turns off printer motor 
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TN300, 1200 
continued 


CONTROL CODES (continued) 


><ESCK 
><ESCL 


><ESC: 


><ESC; 
><FFV 


><HTV_ 
><LFV 


P<VTV 


turns on auxiliary device 


turns off auxiliary device 


resumes printing 


Stops printing, allows transmission 

applicable only for TN1200, throws paper to top-of -page 
(option : fixed setting to 8, 85 or 11 inches) 

moves print to next tabulation stop or end-of-line 


advances paper depending on model, 

» if TN300, one or two lines up (switch sete shiny: 

« if TN1200, one line up (switch selectable, 3 or 6 lines per ae 
applicable only for TN1200, advances paper to next pvereieas tabulation 
stop or a a 


a 


Refer to respective product manuals. 


(6-32 


TTS7800 


| TTS7800 operates on VIP line procedure 


TTS7800 DISPLAY/ KEYBOARD 
The screen is organized in 12 or 24 lines of 80 character positions. 
The optional plasma’-screen is organized in 6 or 12 lines of 40 characters. 


The keyboard has 64 keys and is organized a follows, 
e an alphanumeric pad adaptable for national key layout options 
e a numeric pad a 
« a selection of 13 fixed function-keys 
« a Selection of 8 variable function-keys. 


Variable function-keys are used in conjunction with the fixed function-keys to 
select transactions via a menue 


Header for Display/Keyboard 


The 3 parameters in the VIP header have the following values, 
» STA=EBCDIC OO=COBOL Collating Sequence 1 
o FC1=last function code entered on the keyboard or echo to the application 


o FC2=last but one function code entered or echo to the application. 


Text for Display 


BLANKING : 


><CA1 displayed as a "space" or graphic starts a character string which is 
blanked out on display. 
A "space" or end-of-line ends the blanking. 


BLINKING :| 


><BEL or ><BLK or graphic ‘are displayed as graphic 
character stringe 
A "space" or end-of-line ends the blinking. 


& 


and starts a blinking 


COBOL 3: 


- LINE and PAGE keywords have the same effect as ><BO3 and ><BO1 respectively, 
when used in a clause with the SEND verb. 


_ TTS7800 © 
~ eontinued 


ENTRY MARKER :; 
The foiveutts terminal control codes in meee form alter the current entry po- 
sition, | 
_ ><BO1 as for ><DC4, with display memory cleared, i. e+, screen aeasea 
><BO3 equivalent to the Sequence ><CRV><LFV 
><BSV same line, 1 character position to the left 
><CRV same line, leftmost character position 
2><DC1 one line up, same character position, iwe, reverse line feed | 
><DC2 same line, 1 character position to the right, ieee, forward space 
><DC3 position cursor according to line number and character position 
_><DC4 uppermost line, leftmost character position, i.e., page return 
-2<DEL follows ><HTV, P<FFY, ><BO1 as a "time-fill" 
_ ><FFV same as ><BO1 
><HTV same line, first tabulation to the right 
><LFV one line down, same character position 
><NLV same as ><BO3 | 


To position the cursor, proceed as follows using the ASCII table 

« Determine the value to be given for the line number, Say, 4 
- Start from ASCII code 20 which is a "space" | 
- Count 4 codes from ASCII code 20 inclusive 
- The ASCII code arrived at is 23 
- The EBCDIC equivalent is 7B or graphic # 

- Determine the value to be given for the character position, say, 15 
- Use exactly the same method as above for the line number 
- The EBCDIC equivalent is 4B or graphic. 


- In the MCS application, send a control sequence in one of the formats : 


><DC37#*. using graphic symbols 


><DC3><C7B><C4B using EBCDIC values in control character form 
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TTS7800 
continued 


FORMS MODE :; 


The following terminal control codes in mark form set the terminal either in 
forms mode or in normal mode. 


Forms are defined while in normal mode. 

><ESCM enters the terminal into forms mode 

><ESCN resets the terminal into normal mode 

><FSV defines the start of a fixed field 

><GSV defines the start of a variable field, followed by a value, as follows 
O the field contains a character to be transmitted and printed 
1 inhibits printing 
2 inhibits transmission 


After the forms definition is completed, the terminal is entered into 
forms mode to allow protected operation under forms control. 


MESSAGE BOUNDARIES : 


In normal mode, message boundaries can be controlled by the application using 
the following control codes, 
><ESCT start of message boundary 


><ESCU end of message boundary. 


TABULATION 3; 


The following terminal control codes in mark form set the tabulation, | 
-><ESCi sets the tab stops at the current entry marker position 
><ESG2 resets all the tab stops. 
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_ -TTS7800 
continued — 
“TERMINAL SPECIFICS 


Refer to the appropriate product manual. | 
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TTU8124, 8126 


TTU8124/8126 operate on TTY line procedure 


The TTU8124 and TTU8126 terminals are printers with the optional features, 


e keyboard 
e front feed mechanism for inserting single Single sheets 
e paper loop for mechanically setting vertical tabulation and form length. 


The character set for the printer consists of 63 graphic symbols, or 94, if the 
lower case option is present, according to the national options available. 


The print line has a maximum capacity of 132 characters, or 80, as an option 
Characters received with a parity error are printed with the graphic symbol 0 


When the last column position in a line is passed, an automatic new line move- 
ment occurs. 
In the case of the TTU8126, the new line movement can be Suppressed. 


"Paper out!! condition leads to disconnection for a switched line. 


CONTROL CODES 

The following terminal control codes in mark form enable the operational nae 
ling of the printer, 

><BEL sounds an alarm 

><BSY moves printer head one position to the left 

><CRV resets printer head to leftmost column or first tabulation stop 
><ESCO followed by page length character, sets the page length for form feed 


><ESC1 sets a horizontal tabulation at current print position 
(10 positions to the inch; 16 tabulations stops, maximum) 


><ESC2 clears all horizontal tabulations during operation 
(horizontal tabs are automatically cleared at power-on) 


><ESC3 sets a vertical tabulation at current line count 
| (6 lines to the inch; 10 tabulation stops, maximum) 


><ESC4 clears all vertical tabulations during operation 
(vertical tabs are automatically cleared at power-on) 


><FSV ejects single sheets, automatically performed when less than 1 inch 
from bottom of the sheet. 


><GSV position single sheet to first print position, about half inch from top 
of the sheet | 


><HTV moves printer head to next horizontal tabulation or end-of-line 
><LFV advances paper one line | 


><VIV = advances paper to next vertical tabulation or top-of-page 
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TTU8124, 8126 — 
continued — : 


‘TERMINAL SPECIFICS — 


Refer to the respective product manuals. | 


tne @, 
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TTU8221 


| TTU8221 operates on VIP line procedure | 


The TTU8221 is equipped with a keyboard and a printer with a buffer capacity of 
960 characters. 


95 different graphic symbols can be printed, basically the full ISO ASCII set, 
with variations depending on national keyboard options. 


Its visibility to the host is that of a VIP7700 terminal with limited functions. 


TTU8221 KEYBOARD/ PRINTER 
The page is organized according to parameters entered either by the operator or 
from the application. 


Data entered on the keyboard is placed in a buffer, where editing can be carried 
out by the operator before the data is transferred to the host. 


Printer and medium specifications are, 
» & page is composed of from 10 to 90 lines 


o a line contains from 38 to 132 characters, the default value being 132 cha- 
racters 


eo paper width varies from 4" (10 ems) to 15" (38 cms) 
o Characters are 10 to the inch | 
- lines are 6 to the inch 


e the minimum margin between the sprocket hole and the first character is \", 
measured from center-to-center. 


Header for Keyboard/Print 


The 3 parameters in the VIP header have the following values, 


» STA=EBCDIC 3F =COBOL Collating Sequence 64, 
- when sent by the terminal 
- and, as forced by BINS 


o STA=EBCDIC OO=COBOL Collating Sequence 1, 
- aS received by the application 


‘. FCi=value as received by the application or overridden by the terminal 
operator | 


e FC2="¥"', when the last character has been printed on fanfold paper 


o FC2="!", when the last character has been printed on single forms. 
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 -7Tu8221 
continued 


ventre! Codes 

The PoHlowies estatddl contro? doles in mark form perform the mechanical zune* 
_tions of the printer, _ | 
><B01 new page, or form feed 

_ ><BO03 = new line | 
_ ><CRV><LFV see ><BO3 


| ><pc2 if preceding the following control codes in mark form, will perform a 
| double paper movement for fanfold, namely, 


- ><BO1 

- ><FFV 

- ><LFV. 

- ><VIV 

_><DC3_ set page dimensions according to the number of lines and characters/line 
><ESC1 set horizontal tabulation, up to 10 tab stops may be set in a line 
><ESC2 clear all horizontal tabulation ‘stops | 
><ESCS” set vertical tabulation, up to 10 tab stops may be set in a page 
><ESC6 clear all vertical tabulation stops — 

_><FFV see ><BO3_ | 

><G2F sound a short acoustic signal 

><HTV move print head to next horizontal tab stop, end-of-line is tab stop 
_ ><NLV see ><BO3 oe | ' 

-><VTV_ skip paper to next horizontal tab stop, top-of-form is tab stop 


TTU8221 
continued 


To set the page dimensions, proceed as follows using the ASCII table 


« Determine the value to be given for the number of lines, from 10 to 90, 
inclusive, say the number required is 55 lines 


- Subtract 9 from the number of lines required, that is (55 - 9) =46 
- Start from ASCII code 20 which is a "space" | 

- Count 46 codes from ASCII code 20 inclusive 

- The ASCIT code arrived at is 4D 

The EBCDIC equivalent is D4& or graphic M 


e Determine the value to be given to the number of characters per line, 
from 38 to 132 inclusive, say the number required is 80 characters/line 


- Subtract 37 from the number of characters/line, ieee, (80 - 37) =43 
- Use exactly the same method as above for the number of lines 


- The EBCDIC equivalent is D1 or graphic J 


e In the MCS application, send a control sequence in one of the formats : 
| ><DC3MJ_ using graphic symbols | 
| ><DC3><CD4><CD1 using EBCDIC values in control character form 
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- TTU8221 

continued 

TTU8221 FRONT FEED 
When the option is present, single sheets may be inserted from the front between 
the guides independent of the tractor mechanism 7 , 


Printer and medium specifications are, 


« the vertical print area is 9 less than the total number of lines defined for 
the sheet 


° the number of characters per line is set at 40, 48, 72 or 80. 


The header for the normal traction praneee as described previously, also apertce 
to the "front- feed" printer. | 7 


Control Codes 
The control sage listed for the re traction printer as described previous ly | 
also apply to the "front- feed" printer. = | 


The additional control core in mark form which apply specifically to the "front~ 
feed" printer are, | 


><DC2 if preceding the £Gi lowing control codes in mark tenis, will perform a 
double paper movement for single sheet, namely, 


- ><BO1 

- ><FFV 

- ><LFV | 

- ><VIV ~ | | : 


><ESC3 select single sheet for printing and move head to first print position 
on Single sheet 


><ESC4 select fanfold for printing and move head to first print position on fan- 
fold. 
This is selection by default at "power-on" and is only resorted to after 
the single sheet is ejected by "form-feed" or by excessive paper skips. 
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TTY33, 35, 37, 38 


| TTY33/35/37/38 operate on TTY line procedure 


The TTY33, TTY35, TTY7 and TTY38 are printers with the options, 
« keyboard 


e paper tape attachment. 
The keyboard can send either 96 or 128 ISO codes, depending on the model. 


The character set for the printers comprises 63 graphic symbols, or 94 for the 
TTY37 and TTY38. 


Line length is either 72 or 86 characters. 


CONTROL CODES 


The applicability of the control codes shown in mark form depends on the model 
and the installed options. 

><BEL rings a bell 

><BSV moves print position one character to the left. 
><CRV resets print position to leftmost margin 

><DC1 starts paper tape reader 

_2><DC2 starts paper tape punch 

><DC3 stops paper tape reader 

><DC4 stops paper tape punch 

><ESCi sets horizontal tabulation at current print position 
><ESC2 clears all horizontal tabulations during operation * 
><ESC3 selects printing in red 

><ESC4 selects printing in black 

><ESC5 sets vertical tabulation at line count 

><ESC6 clears all vertical tabulations during operation * 
><ESC7 rolls back paper one line 

><ESG8 rolls back paper half a line 

><ESC9 advances paper half a line 

><FFV advances paper to top-of-page (next page) | 
><HTV moves print position to next tabulation stop on the same line 
><LFV advances paper one line (3 or 6 lines to the inch) 


* At power-on, all vertical and horizontal tabulations are automatically cleared. 
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-—- TTY33, 35, 37,38 
continued 
TERMINAL SPECIFICS | 


_ Refer to the respective product manuals. 


> a 
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VIP7001 
* 


| VIP7001 operates on VIP line procedure 


VIP7001 DISPLAY/ KEYBOARD 


The screen is organized in 12 or 24 lines of 80 characters. An option is avail- 
able for 22 lines of 46 characters. Including the "space", 64 different graphic 
symbols, or 95 with lower case option, can be displayed. The types of graphic 
symbols depend on national options. An entry marker is displayed as an aid in 
formatting the screen. 


The FORMGEN utility is available for formatting the screen. The FORMRTP utility, 
the Forms run-time package, is then executed. 


Header for Display/Keyboard 

The 3 parameters in the VIP header have the following values, 
» STA=EBCDIC 00=COBOL Collating Sequence 1 
« FC1=last function code entered on the keyboard or echo to the “application 
e FC2=last but one function code entered or echo to the application. 


Text for Display 


BLANKING ;3 


><CA1 displayed as a "space" or graphic starts a character string which is 
blanked out on display. 
A "space" or end-of-line ends the blanking. 


BLINKING : 


><BEL or ><BLK or graphic’ are displayed as graphic “ and starts a blinking 
character string. 
A "space" or end-of-line ends the blinking. 


COBOL : 


LINE and. PAGE keywords have the same effect as ><BO3 and ><BO1 Sesbeereue 
when used in a clause with the SEND verb. 


A~A& 


VIP7001 
continued 


_ ENTRY MARKER : 
The feiieetne terminal control codes in mark form alter the current entry po- | 
sition, | | | | | | 

. 2<B01 as for ><pe4, with display memory cleared, i.e, screen erased 
><BO3 equivalent to the sequence ><CRVD><LFV 
><BSV Same line, 1 character position to the left 
><CRV same line, leftmost character position 
><DC1 one line up, same character position, ieee, reverse line feed | 
><DC2 same line, 1 character position to the right, iee., forward space 
><DC3 position cursor according to line number and character position 
><DC4 uppermost line, leftmost character position, i.e., page return 

_ ><DEL follows ><HTV, ><FFV, ><BO1 as a "time-fill" 
><FFV same as ><BO1 | 
D<HTV same line, first tabulation to the right 
><LFV one line down, same character poste toy | 
><NLV same as ><BO3 


To position the cursor, proceed as follows uSing the ASCII table 
- Determine the value to be given for the line number, Say 12 
- Start from ASCII code 20 which is a "space" 
- Count 12 codes from ASCII code 20 inclusive 
- The ASCII code arrived at is 2B 
| - The EBCDIC equivalent is 4E or graphic + 
- Determine the value to be given for the character position, say, 6 
- Use exactly the same method as above for the line number 
- The EBCDIC equivalent is 6C or graphic % 


« In the MCS application, send a control sequence in one of the formats ; 


><DC3+% using graphic symbols 


7<DC3><C4E><C6C using EBCDIC values in control character form 
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FORMS MODE : 


VIP7001 
continued 


The following terminal control codes in mark form set the terminal either in 
forms mode or in normal mode. | 


Forms are defined while in normal mode. 


><ESCM enters the terminal into forms mode 


><ESCN resets the terminal into normal mode 
><FSV defines the start of a fixed field 
><GSV defines the start of a variable field, followed by a value, as follows 


O the field contains a character to be transmitted and printed 


1 inhibits printing 


2 inhibits transmission 


After the forms definition is completed, the terminal is entered into 
forms mode to allow protected operation under forms control. 


MESSAGE BOUNDARIES ; 


In normal mode, message boundaries can be controlled by the application using 
the following control codes, 


><ESCT start of message boundary 


><ESCU end of message boundary 


PAGE OVERFLOW 


eo 


detection ° 


cause ‘ 


correction . 


TABULATION 3: 


ERROR indicator on the terminal lights up. 


result of a programming error 


result of operator error in failing to clear the screen. 


press CTR and CLEAR control keys simultaneously 
send the command $*$RDY | 


if overflow recurs, send $%*$ RDY STRONG to cancel the message. 


The following terminal control codes in mark form set the tabulation, 


><ESC1 sets the tab stop at the current marker position 


><ESG2 resets all the tab stops. 
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-VIP7001 _ 
continued 


VIP7001 PRINTER | 


Printable text is defined between the control codes in mark form ><STX, to de- 
note "start-of-text" and, either ><ETX or ><EMV, to denote "end-of-text", 
Text output to the printer does not appear on the screen 


© Method of addressing (1) : 
-. address the display/keyboard with STA = 3F in the VIP header. 
The keyboard is locked during printing. 


The message is printed as it is. The text in the message must contain all nec- 
esSary control codes for formatting the text, which are the same as for posi- 
tioning the entry marker for display on the screen. 


Like display on the screen, "time-fills" are required to ensure proper syn- 
chronization of the printer mechanism Any control code which causes movement 
of the printer mechanism, such as "carriage-return" and "line-feed", must be — 
immediately followed by a sequence of "time-fills", ><DEL, before any text is 
sent to be printed. Full line size capability is obtained by this method. 


© Method of addressing (2) : 


« define the printer by a separate TERMNL command declaring the "terminal- 
subtype" as PRT at CNC generation 
- address the display/keyboard with STA=00O in the VIP header. 


The keyboard is not locked and may be used to enter data into the screen and 
to transmit the data while printing proceeds. 


Data is printed according to the standard VIP7001 hard copy Keuat with a max- 
imum line length of 80 characters. Print format controls, such as "'carriage- 
return'' and "line-feed'"', are generated automatically by the terminal controll- 
ere 


° Method of addressing (3) : 


« define the printer by a separate TERMNL command declaring the "terminal- 
subtype" as PRT at CNC generation 
- address the display/keyboard with STA=3F in the VIP header. 


The keyboard is not locked and may be used to enter data into the screen and 
to transmit the data while printing proceeds. 


The message is printed as it is. The text in the message must contain all nec- 
esSary control codes for formatting the text, which are the same as for posi- 
tioning the entry marker for display on the screen. 


Like display on the screen, "time-fills" are required to ensure proper syn- 
chronization of the printer mechanism Any control code which causes movement 
of the printer mechanism, such as "carriage-return" and "line-feed'', must be 
immediately followed by a sequence of "time-fills", D><DEL, before any text is 
sent to be printed. Full line size capability is obtained by this method. 
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VIP7100 


NIP7100 operates on TTY line procedure | 
The VIP7100 is a keyboard/display terminal. 


Entry of data in the display starts at the bottom line and on completion, the 
line is "rolled up" if the new line function has been provided for. 

Otherwise, excess characters overprint the rightmost character position, that is, 
position 80. 


The "home" position defines the leftmost character position of the bottom line. 
A cursor is displayed to facilitate data entry. 


Screen capacity is 12 lines of 80 characters, with an option available for 24 
lines. 


The character set for the display consists of 63 graphic symbols, or 94, if the 
lower case option is presente 


The keyboard can send any of the 128 ISO codes, however, if only the upper case 
is present, the set is reduced to 94, 


CONTROL CODES 

The following terminal control codes in mark form enable the operational hand- 
ling of the display, | | 

><BEL sounds an alarm 

><BSV moves cursor one position to the left 


><CRV resets cursor at the left margin, without affecting characters already 
displayed on the line 


><DC2 moves cursor one position to the right 
><FFV resets cursor to the left margin for erasing the screen 


><LFV "rolls up" lines by one line in order to allow data entry into the bot- 
tom line 


6-49 


- VIP7100 — 
continued | 


TERMINAL SPECIFICS 


Refer to the appropriate product manual. 
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~VIP7200 


_ ‘VIP7200 operates on TTY line procedure 
The VIP7200 is a keyboard/display terminal. 


A cursor is displayed to indicate the current entry position. The screen is 
Filled from the top, progressing line by line to the bottom When the last line 
at the bottom is filled, the contents of the screen are automatically "rolled 
up" by one line in order to allow further data entry. 


Screen capacity is 24 lines of 80 characters. 


The character set for the display consists of 63 graphic symbols, or 94, if the 
lower caSe option is present. 


The keyboard can send any of the 128 ISO codes. 


CONTROL CODES 

The following terminal control codes in mark form enable the operational hand- 
ling of the display, 

><BEL acoustic Signal to the operator 

><CRV reset cursor at left margin on the same line 

><ESC3 set normal intensity for screen illumination 

><ESC4 set low intensity for screen illumination 

><ESCA move cursor one line up but at the same character position 
><ESCB move cursor one line down but at the same character position 
><ESCC move cursor one character poSition to the right on the same line 
><ESCD move cursor one character position to the left on the same line 


><ESCH reset cursor in "home" position, ieee, at leftmost character position 
| at the top of the screen 


><ESCJ erase text display from current cursor position to the end-of -page 
><ESCK erase text display from current position to the end-of-line 
><ESC' reset terminal to initial state, as follows, 

e erase the Screen 

eo set cursor to "home" position 

e set normal intensity for screen illumination. 

The equivalent control sequence is ><ESC><C79. | 

><ESC£ position the cursor according to character position and line number 


><ESCi send data from the start-of-line or start- of-pages depending on switch 
setting, to the current cursor position 
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_VIP7200 
continued 


CONTROL CODES ( continued) 


><ESCn ‘terminal. to indicate its cursor position according to the format given: 
: in ><ESCE£ 


><LEV move cursor one line down; if the cursor is on Eee bottom line, "roll 
up" wilt occur | 


To position the cursor, proceed as follows using the ASCII table © 
- Determine the value to be given for the character position, Say, 37 
| - Start from ASCII code 20 which is a "space!" | | 
- Count 37 codes from ASCII code 20 inclusive 
The ASCII code arrived at is 44. 
_- The EBCDIC equivalent is C4 or graphic D 


. Determine the value to be given to the line number, say, 11 
_- Use exactly the same method as above for character position 
- The EBCDIC equivalent is 5C or graphic * 


-. In the MCS application, send a control sequence in one of the formats : 


><ESC£D* using graphic symbols 


><ESC£ ><CC4><C5C using EBCDIC values in control character form 
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VIP7700 


VIP7700 operates on VIP line procedure | 


VIP7700 DISPLAY/KEYBOARD . 


The screen is organized in 12 or 24 lines of 80 characters. An option is availa- 
ble for 22 lines of 46 characters. Including the "space", 64 different graphic 
symbols, or 95 with lower case option, can be displayed. The types of graphic 
symbols depend on national options. An entry marker is displayed as an aid in 
formatting the screen 


The FORMGEN utility is available for formatting the screen. The FORMRTP utility, 
the Forms run-time package, is then executed. 


Header for Display/Keyboard 


The 3 parameters in the VIP header have the following values, 


e STA=EBCDIC O0=COBOL Collating Sequence 1 | 
e FCi=last function code entered on the keyboard or echo to the application 
o FC2=last but one function code entered or echo to the application. 


Text for Display 


BLANKING : 


><CA1 displayed as a "space or graphic starts a character string which is 
blanked out on display. 
A "space" or end-of-line ends the blanking. 


BLINKING 8 


><BEL or ><BLK or graphic ™ are displayed as graphic ~*~ and starts a blinking 
character string. 
A "space" or end-of-line ends the blinking. 


COBOL 3; 


LINE and PAGE keywords have the same effect as ><BO3 and ><BO1 respectively, 
when used in a clause with the SEND verb. 


- VIP7700 © 
~ continued 


ENTRY MARKER : 


The goliewias terminal control epllse in mark form alter the current entry po- 
sition, 


><BO1 as for ><De4, with display memory cleared, ieee, screen erased 
><B03 equivalent to the sequence ><CRV><LFV | 

><BSV same line, 1 character position to the left 

><CRV same line, leftmost character position 

><DCi one line up, same character position, iee., reverse line feed 
><DC2 same line, 1 character position to the right, ieee, forward space 
><DC3 position cursor according to line number and character position 
><DC4 uppermost line, leftmost character position, ieee, page return 
><DEL follows ><HTV, ><FFV, ><BO1 as a "time-fi11" 

><FFV same as ><BO1 | 

><HTV same line, first tabulation to the right 

><LFV one line down, same character position 

><NLV same as ><BO3 


To position the cursor, proceed as follows using the ASCII table 

- Determine the value to be given for the line number, say, 11 
- Start from ASCII code 20 which is a "space" 
- Count 11 codes from ASCII code 20 inclusive 
- The ASCII code arrived at is 2A 
- The EBCDIC equivalent is 5C or graphic * | 

» Determine the value to be given for the character position, say, 37 
- Use exactly the same method as above for the line number 
- The EBCDIC equivalent is C4 or graphic D 


« In the MCS application, send a control sequence in one of the formats : 


><DC3*D using graphic symbols 


><DC3><C5C><CC4 using EBCDIC values in control character form 
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VIP7700 
continued 


FORMS MODE : 


The following terminal control codes in mark form set the terminal either in 
forms mode or in normal mode. 


Forms are defined while in normal mode. 

><ESCM enters the terminal into forms mode 

><ESCN resets the terminal into normal mode 

><FSV defines the start of a fixed field | 

><GSV defines the start of a variable field, followed by a value, as follows 
O the field contains a character to be transmitted and printed 
1 inhibits printing 
2 inhibits transmission 


After the forms definition is completed, the terminal is entered into 
forms mode to allow protected operation under forms control. 


MESSAGE BOUNDARIES :; 
In normal mode, message boundaries can be controlled by the application using 
the following control codes, 
><ESCT start of message boundary 
><ESCU end of message boundary 


PAGE OVERFLOW :; 
detection : ERROR indicator on the terminal lights up. 


cause ; Either one of the following conditions has occurred 
e a result of a programming error 
o a result of an operator error in failing to clear the screen 


correction: Perform the following sequence of operations 
« press CTR and CLEAR control keys simultaneously 
o send the command $*$RDY 


e if overflow occurs again as a result of message length, send the 
command $*$RDY STRONG to cancel the message. 


TABULATION : 


The following terminal control codes in mark form set the tabulation, 
><ESCi sets the tab stop at the current entry marker position 
><ESCG2 resets all the tab stops. 
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— VIP7700 — 
continued — 
VIP7700 PRINTER 


Printable text is defined between the control codes in mark form ><STX, to de- 
note "start-of-text" and, either ><ETX or ><EMV, to denote "end-of - text". 


Text output to the printer does not peppeee on the screen. 


° Method of addressing (1) : 


» address the display/keyboard with STA =3F in the VIP header. 
The keyboard is locked during printing. 


The message is printed as it is. The text in the..message must contain all nec- 
esSary control codes for formatting the text, which are the Same as for posi- 
tioning the entry marker for display on the screen. 


Like display on the screen, '!time-fills" are required to ensure proper syn- 
chronization of the printer mechanism Any control code which causes movement 
of the printer mechanism, such as "carriage-return'' and "line-feed", must be 
immediately followed by a sequence of "time-fills", D><DEL, before any text is 
sent to be printed. Full line size capability is obtained by this method. 


© Method of addressing (2) : 


- define the printer by a separate TERMNL command declaring the "terminal- 
subtype"! as PRT at CNC generation 
- address the display/keyboard with STA=00 in the VIP header. 


The keyboard is not locked and may be used to.enter data into the screen and 
to transmit the data while printing proceeds. 


Data is printed according to the standard VIP7700 hard copy format with a max- 
imum line length of 80 characters. Print format controls, such as ''carriage- 


return" and "line-feed", are generated automatically by the terminal controll- 
Cre | 


© Method of addressing (3) : 


« define the printer by a separate TERMNL command declaring the "terminal- 
subtype" as PRT at CNC generation 


» address the display/keyboard with STA=3F in the VIP header. 


The keyboard is not locked and may be used to enter data into the screen and 
to transmit the data while printing proceeds. 


The message is printed as it is. The text in the message must contain all nec- 
essary control codes for formatting the text, which are the Same as for posi- 
tioning the entry marker for display on the screen. 


Like display on the screen, "time-fills'' are required to ensure proper Syn- 
-chronization of the printer mechanism. Any control code which causes movement 
of the printer mechanism, Such as "'carriage-return" and "line-feed", must be 
immediately followed by a sequence of "time-fills", ><DEL, before any text is 

sent to be printed. Full line size capability is obtained by this method. 
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VIP7760 


NIP7760 operates on VIP line procedure 


VIP7760 DISPLAY/KEY BOARD 


The screen is organized in 12 or 24 lines of 80 characters. Including the "'space"' 
95 different graphic symbols, basically ISO/ASCII set with national options, can 
be displayed. An entry marker is displayed as an aid in formatting the screen. 


The FORMGEN utility is available for formatting the screen. The FORMRIP utility, § 
the Forms run-time package, is then executed. . 


Text for Display 


The control sequences for tabulation, entry marker control and message boundaries 
are the same as for the VIP7700. Blinking and blanking are supported as options. 


FORMS MODE 
The following terminal control codes in mark form set the terminal either in 
forms mode or in normal modee Forms are defined when in normal mode. 
>< ESCM enters the terminal into forms mode | 
><ESCN resets the terminal into normal mode 
>< FSV defines the start of a fixed field 
><GSV defines the start of a variable field, followed by a value, as follows 


O the field is right-justified, non-repeated and alphanumeric, to be 
transmitted and printed 


1 inhibits printing 
2 inhibits transmission 
4 mnumeric-only field 
8 indicates a number of a line field to be repeated 
16 the field is left-justified 
>< RSV terminates a repetitive line field, followed by a repetition code 


value of repetition code : add 64 to the number of times that the line 
field is to be repeated. 
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VIP7760, 
continued 


- VIP7760 PRINTER’ 


‘The printer must be defined by a separate TERMNL command declaring the "terminal- 
subtype" as PRT at CNC generation. Text for printing can only be sent to the prin- 
ter address. The three printing modes are treated as sila» 


TRANSPARENT MODE 
Method of addressing : Either | 
- address the pviviter with STA=3F in the VIP header 


Or | 
« address the printer with STA=00 in the VIP header 
-« and, precede the text with ><ESCZ. — 


The message is printed as it is. The text in the message must contain any neces- 
Sary format control codes, see "Text for Display", and any other control codes 
specific to the printer. , 


"Time-fill" control codes for the proper mechanical synchronization of the prin- 
ter should also be included in the message texte | 


><uUSV defines the "time-fill" count, in the case where hes printer is used 
for hard copy, and where the proper Emer oeeaaene™ of the printer me- 
chanism is PSDEGS: 


To define the "time-fil1" count, proceed as follows using the ASCII table 
« Determine the value to be given for the number of "time-fills", say, 4 
- Start from ASCII code 20 which is a "Space" 
- Count 4 codes from ASCII code 20 inclusive 
- The ASCII code arrived at is 23 
- The EBCDIC equivalent is 7B or graphic # 


« In the MCS application, send a control sequence in one of the formats : 


><USV# using the graphic symbol © 


><USV><C7B using the EBCDIC value in control character form 
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VIP7760 
continued 


VIP7760 PRINTER (continued) 


DISPLAY IMAGE MODE : 


Method of addressing : 


e address the printer with STA=00 in the VIP header 
e and, end the message text with ><ESCN. 


The message text may optionally begin with ><ESCX or ><ESCY. 


The text is formatted automatically on the printer according to the display 
format characteristics. 


Printer control functions and “time-fills'' are generated automatically by the 
VIP7760 system 


FORMS MODE : 


Method of addressing ; 


» address the printer with STA=00 in the VIP header 
e and, end the message text with ><ESCM. 


If the message text begins with ><ESCX, only the variable fields will be prin- 
ted. : 


If the message text begins with ><ESCY, both the fixed fields and the variable 
fields will be printed. 


If the message text is not preceded by either ><ESCX or ><ESCY, it will not 
be printed. 


Variable fields defined as "inhibit-printing" will not be printed. 
The printer is controlled. automatically by the VIP7760 system 
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VIP7760 
continued — 


VIP7760 DISKETTE 
The diskette unit must the defined by a separate TERMNL peamaa declaring ‘he 
"terminal-subtype'" as DSK at CNC generation. 


| Messages with STA= 00 in the VIP header can be tcheegat between the application 
and the unit, where the appropriate control sequence indicates that the message 
that would otherwise appear on the screen is destined for the diskette unit. 


‘The diskette is used for forms management in the following wayS, 


« a form is stored by transmitting the form data, for formatting the screen, | 
together with the necessary "dataset" name and form label, and the "diskette- 
- write" control sequence, ><ESCW | 


« during a communications session, a form is retrieved, for avnenvdal ig format - 
ting the screen, by transmitting the "dataset" name and form label, and the 
"diskette-read" control sequence, ><ESCV 


» a form is deleted by transmitting the "dataset" name and the BORD) TEPER and 
the "diskette-erase" control sequence, 7<ESCQ. 


The diskette control sequences must be placed after ><STX in the text portion of 
the message, but are not initiated until 7<EIX received. 


Control Gode Sequences 


In the following explanation of control sequences, it is assumed that 
« the diskette is operational 
. the "dataset" name is valid and has been entered before the control sequence 


» the form name is not identical to one listed in the catalog. 


The control sequences are listed in order of their functions, 


><ESCW initiates the storage of a form under the specified "dataset" name and 
form label | 


><ESCV retrieves a local form and initiates the transmission of the form con- 
tents to the host, under the specified "dataset" name and form label 


For both the P<ESCV and ><ESGW control sequences, the keyboard remains 
locked. 


><ESCQ erases a single form or forms from a Ndataset" as follows, 
- a Single form is erased, if both the "dataset" name and form label 
are specified 
» forms are deleted from the "dataset", if the "dataset" name is spec- 
ified, and then followed by the keyword $ALL | 


><ESCB enables the local display without transmit of a form under the speciticd 
"dataset" name and form label. 
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VIP7802 


| VIP7802 operates on TTY line procedure 


The VIP7802 identifies the VIP7801 and VIP7802. 


The screen is formatted in 24 lines of 80 characters, plus a 25th 80-character 
Status line. This status line serves as a constant indicator of the terminal op- 
erating conditions, such as, terminal mode, terminal status and cursor position. 


The keyboard is capable of producing 139 displayable characters, of which, 


e 95 are Standard ASCII characters, including the "space" and the lower-case 
option 


e 33 are graphic symbols used in "communications display" mode 
» 11 are line graphic symbols for line drawings, histograms and form outlines. 


The position of the character to be displayed is indicated by the current posi- 
tion of the cursor which can be selected either as an "underscore" (_) or as a 
block. 


The VIP7801/7802 transmits in three modes, 


« character mode, in which information is transmitted as it is being keyed in, 
character at a time 


o text mode, in which the terminal transmits from either the lst character en- 
tered since the last transmission or a pre-defined position set by the Level 
64, to the current cursor position 


« forms mode, in which data to be transmitted is determined by the forms attri- 
butes qualifying each field. 


ATTRIBUTES 


The following control code sequences in mark form indicate the specific attribute 
to be stored at the current cursor position. 


>< ESC s "visual", screen display in normal intensity 

><escs{Ala} "forms", restricts entry to alpha-characters and normal punctua- 
tion marks for editing 

><Esc s{B]b} "visual", data and underscore to blink, inverse video is not 
affected , | | 

P<ESG s{ Dla} "forms", restricts entry to decimal digits and "space" 
negates ><ESC s i N[|n} 

><EsC s{Ele} "forms", entry required before tabbing from the field 

><escs{Flf} "forms", field must be completely filled before tabbing 

><ESC s{ H[h} "yisual't, data entered is not to be displayed, inverse video and 


underscore are not affected 
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- VIP7802 
_ continued 


ATTRIBUTES (continued) | 


 -><escs{1{i} 
><ESC s | J] j 
><ESC s{L 

><ESC s{M 


><esc s{n[n 


><ESC s Plp 


><ESC s Rly} 


—><esc s{T[t 
><ESC s{u lu 


><ESCs _ 


L1y 
fm} 


"visual", inverse video 


"forms", £ield entry to be right justified — 
"visual", screen display in low intensity 


"forms", field to be transmitted o nly if its contents is changed 


negates ><escs{t[t } » sets S<escs {uful 


"forms", restricts field to signed decimals and value indicators 
negates ><ESC s{D]d} | 


"forms", defines protected field without changing | other attributes 
modifies S<ESC s {Mm} and ><Esc s{ulu} 


"restore", negates attributes set for a field without altering GRE 
field assignment 


"forms", transmits the contents of a protected field 


"forms", defines unprotected field whereby data is to be systema 


tically transmitted and made accessible to the operator 


"forms", display underscore 


To set up a form, proceed as follows, | 

. send ><ESC‘ ><EsCf h to clear the screen and set terminal in forms mode 
» position cursor at Start of ist field to enter "attribute", then contents 
e repeat same procedure for all fields until the form is completed. 


To delete any attribute, send the control code sequence ><Esc[ Q | 


KEYBOARD 


><esc [ X es keyboard, disables all keyboard Ainctiode except for RIS, RES, 
AUTO-LF, LOCAL and BREAK 


><esc [ W unlocks keyboard, negates ><eEsc [ X 


TABULATION : 


also see "Cursor" 


><ESC p sets tab stop at current cursor position; invalid in forms mode 


><esc [ g clears tab stop, negates ><ESC p; invalid in forms mode 


><esc [ N clears all tabs irrespective of cursor position; invalid in forms mode 


><es¢ [ Z moves cursor backwards to the previously defined tab position 


><HTV  =-—s moves cursor forwards to next character position at which the tab was 
~~ ‘set; if in forms mode, cursor moves to start of next BAPEOEeEECS field 
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CURSOR 


><BSV 


><CRV 
><ESC A 


><ESC B 
><ESC C 
><ESC D 


><ESC f£ 
><ESC H 
><ESC n 


><LFV 


VIP7802 
continued 


also see. "Tabulation" 


moves cursor 1 character position backwards on same line, regardless 
of fields transversed; cursor does not move out of position 1 


reset cursor at left margin, character position 1, on same line 


moves cursor upwards by 1 line, same character position; when in line 
1, cursor moves to line 24 


moves cursor downwards by 1 line, same character position; when in 
line 24, cursor moves to line 1 


moves cursor forwards by 1 character position along same line; when 
out of position 80 of line 24, cursor moves to "home" position 


moves cursor backwards by 1 character position along same line; when 
out of “home'' position, cursor moves to position 80 of line 24 


positions cursor according to character position and line number 
moves cursor to the "home" position 


terminal to indicate its curSor position in the status line, accord- 
ing to the format given in ><ESC£ 


moves cursor downwards by 1 line; if cursor is already in line 24, 
e in "roll" mode, data is rolled up by 1 line 
« in '"non-roll'' mode, cursor does not move and "data-overflow'' occurs 


To position the cursor, proceed as follows using the ASCII table 


e Determine the value to be given for the character position, say, 37 


- Start from ASCII code 20 which is a "space" 
- Count 37 codes from ASCII code 20 inclusive 
- The ASCII code arrived at is 44 

- The EBCDIC equivalent is C4 or graphic D 


o Determine the value to be given to the line number, say, 11 


~ Use exactly the same method as above for character position 


- The EBCDIC equivalent is 5C or graphic * 


© In the MCS application, send a control sequence in one of the formats :; 


><ESCED*. using graphic symbols 


><ESC£ ><CC4><C5C using EBCDIC values in control character form 
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‘VIP7802_ 
continued © 


EDITING 


| ><ESC J 


><ESC K 


-><esc [ 


-><esc [ 
><esc [ 


><Esc [ 


><esc [ 


MODE 
><ESC F 
><ESCG 


><ESC I 


><ESC k 
><ESC q 
><ESC r 


><esc [ 
><esc [ 


><esc [ 


><esc [ 
><ESC * 


Cy 


- 
blocki block2 block3 block4 F 


h 


1 


erases to end of page starting from current cursor position, tabs 
and attributes remaining unaffected; in forms mode, only unprotected 


data is erased 


erases to end of field starting from current cursor position; not 
valid if cursor is already in character position 80 


allows characters to be inserted at current cursor position; data 
Surpassing line width is truncated 


negates ><ESC[ I 


inserts single blank line at line indicated by cursor; invalid in 
forms mode or. when cursor is in the status line 


deletes line in which cursor is located, including all attributes 


deletes character within a line whereby all text is closed up to the 
left, tabs and attributes remaining unaffected 


‘resets the line graphics mode, negates ><ESCG 


sets terminal in line graphics mode, in which any of the 11 line 
graphic symbols can be used 7 


causes terminal to transmit next block when in block transmission 
mode > : 


sets terminal in Chavacver mode 


resets the roll mode, negates ><ESCr 


sets terminal in roll mode unless terminal is in forms mode 


resets the block transmission mode 


sets terminal in block transmission mode according to the block-size 
designated; invalid if terminal is in character mode 


sets terminal in forms mode, whereby ‘data can only be entered in un- 
protected fields 


sets terminal in text mode, whereby data can be entered anywhere © 


resets screen to initial state as follows, 

« erase the screen 

» set cursor to "home'' position 

e set text mode 

» clear all attributes 

e set normal intensity for screen illumination | 
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VIP7804 


_ MIP7804 operates on VIP line procedure | 


The VIP7804 identifies the VIP7804 and VIP7805. 


The screen is formatted in 24 lines of 80 characters, plus a 25th 80-character 
Status line. This status line serves as a constant indicator of the terminal op- 
erating conditions, such as, terminal mode, terminal status and cursor position. 


The keyboard is capable of producing 139 displayable characters, of which, 


» 95 are standard ASCII characters, including the "space" and the lower-case. 
option 


« 33 are graphic symbols used in "communications display" mode 
e 11 are line graphic symbols for line drawings, histograms and form outlines. 


The position of the character to be displayed is indicated by the current posi- 


tion of the cursor which can be selected either as an "underscore" (_) or as a 
block. 


The VIP7804/7805 transmits in two modes, 


e« text mode, in which the terminal transmits from either the list character en- 
tered since the last transmission or a pre-defined position set by the Level 
64, to the current cursor position 


« forms mode, in which data to be transmitted is determined by the forms attri- 
butes qualifying each field. 


Data buffering in the printer adapter allows printing to take place simultaneous- 
ly with screen display. The adapter provides maximum buffering for up to 100 
lines of 132 characters per line. The adapter also provides for the control, tim- 
ing and status monitoring of the printer. 


User visibility in addressing printer functions is restricted to ESC control code 
sequences which activate the printer. 


ATTRIBUTES 


The following control code sequences in mark form indicate the specific attribute 
to be stored at the current curSor positione 


><ESC s "visual", screen display in normal intensity 

><ESG s{ala} "forms", restricts entry to alpha-characters and normal punctua- 
tion marks for editing 

><esc sj Blb} "visual", data and underscore to blink, inverse video is not 
affected . 

Zara s{ pa} "forms'"', restricts entry to decimal digits and “space! 
negates ><ESC s{N[n} 

><ESC st Ele} “€orms", entry required before tabbing from the field 
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7 een 


ATTRIBUTES ( cont -inued) 


><ESC s{rle} 


><ESC s}H{h 


><ESC s 


| S<ESC Ss 


t[i 
I|j 
L[1 
M[m 


N[n 


><ESC s R[r 


; 
{ 0| 
P| 
afr] 
{ul 


><ESCS _ 


t 
} 
} 
lo} 
Ip} 
t | 
uf 


"forms", field must be completely filled berore tabbing 


"visual", data entered is not to be displayed, inverse video and 
underscore are not affected 


Nvisual", inverse video 
"forms'', field entry to be right justified 
visual", screen display in low intensity 


"forms", field to be transmitted o nly if its contents is changed 
negates ><Esc s{T[t} » sets S<Esc s {Ulu} 


"forms", restricts field to signed decimals and value indicators © 
‘megates ><ESC s{pD|a} | 


"printer", suppresses printing, also see "Printer" 


"forms'', defines protected field without changing other avtvibutes : 
modifies S<ESC $ {fm} and ><Esc s{ u[u} 


"restore", negates attributes set for a field without altering dae! 
field assignment | 


"forms", transmits the contents of a protected field 


"forms", defines unprotected field whereby data is to be systema- 
tically transmitted and made accessible to the operator 


"forms'', display underscore 


To set up a form, proceed as follows, 


« Clear the screen by sending the control code sequence ><ESC * 


» Set the terminal in forms mode by the sequence ><esc [ h 


« Position the cursor at the start of the ist field, see "Cursor" 


. Enter the "forms" attribute and then the contents of the field 


. Position the cursor at the start of the next field 


. Repeat the operation of entering the "forms" attribute, then the contents 


_« Continue the same procedure until the form is completed. 


To delete any attribute, send the control code sequence ><esc [ Q 
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VIP7804 


_. Continued 
CURSOR : also see "Tabulation" 
><BSV moves cursor 1 character position backwards on same line, regardless 


* of fields transversed; cursor does not move out of position 1 
><CRV reset cursor at left margin, character position 1, on same line 


><ESC A moves cursor upwards by 1 line, same character position; when in line 
1, cursor moves to line 24 


><ESC B moves cursor downwards by 1 line, same character position; when in 
line 24, cursor moves to line 1 


><ESC C moves cursor forwards by 1 character position along same line; when 
out of position 80 of line 24, cursor moves to "home" position 


><ESGD moves cursor backwards by 1 character position along same line; when 
out of "home" position, cursor moves to position 80 of line 24 


><ESC f positions cursor according to character position and line number 
><ESCH moves cursor to "home" position 


><ESC n terminal to indicate its cursor position in the status line, accord- 
ing to the format given in ><ESC£ 


P<LFV moves cursor downwards by 1 line; if cursor is aleady in line 24, 
e in "roll" mode, data is rolled up by 1 line 
e in "non-roll" mode, cursor does not move and "data-overflow'' occurs 


To position the cursor, proceed as follows using the ASCII table 

e Determine the value to be given for the character position, say, 14 
- Start from ASCII code 20 which is a "space" 
- Count 14 codes from ASCII code 20 inclusive | 
- The ASCII code arrived at is 2D 
- The EBCDIC equivalent is 60 or graphic - 

- Determine the value to be given to the line number, say, 20 
- Use exactly the same method as above for character position © 
- The EBCDIC equivalent is F3 or graphic 3 | 


e In the MCS application, send a control sequence in one of the formats ; 


| ><ESC £ -3 using graphic symbols 


><ESC£ ><C60><CF3 using EBCDIC values in control character form 
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-VIP7804 — 

continued 

EDITING 

><ESC J ; erases to end of page Starting from current cursor position, tabs 


and attributes remaining unaffected; in forms mode, only unprotected 
data is erased 7 | 


><ESC K erases to end of field Starting from current cursor position; not 
valid if cursor is already in character position 80 


><ESC [ I allows characters to be inserted at current cursor position; data 
surpassing line width is truncated 


—><esc[ Js negates ><esc[ 1 


><esc [ L inserts single blank line at line indicated by cursor; invalid in 
forms mode or when cursor is in the status line ~ 


><esc [ M deletes line in which cursor is located, including all attributes 


><esc [ P deletes character within a line whereby all text is closed up to the 
left, tabs and attributes remaining unaffected 


KEYBOARD | 

><ESC [ X locks keyboard, disables all keyboard functions except for RIS, RES, 
| _ AUTO-LF, LOCAL and BREAK | | | 

><Eesc [ W unlocks keyboard, negates ><esc [ x - 


TABULATION : also see "Cursor"! 


><ESC p sets tab stop at current cursor position; invalid in forms mode 
-><esc [ g clears tab stop, negates ><ESCp; invalid in forms mode 

><ESC [ N clears all tabs irrespective of cursor position; invalid in forms mode 
><esc [ Z moves cursor backwards to the previously defined tab position 


><HIV moves cursor forwards to next character position at which the tab was 
set; if in forms mode, cursor moves to Start of next unprotected field 
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MODE 


><ESC F 
><ESC G 
><ESC I 
><ESC q 


><ESC r 
><esc[ E 


VIP7804 
continued 


resets the line graphics mode, 
negates ><ESCG 


sets terminal in line graphics mode, in which any of the 11 line 
graphic symbols can be used 


causes terminal to transmit next block when in block transmission 
mode 


resets the roll mode, 
negates ><ESCr 


sets terminal in roll mode unless terminal is in forms mode 


resets the block transmission mode 


><esc [ blocki block2 block3 block4 F 


><esc [ j 


><esc [ 1 
><esc fs 


><esc | tT 
><ESC * 


sets terminal in block transmission mode according to the block-size 
designated 


sets terminal in forms mode, whereby data can only be entered in un- 
protected fields 


Sets terminal in text mode, whereby data can be entered anywhere 


transmits successive blocks of data automatically when in block tran- 
smission mode after the previous block has been ACKed 


allows transmission of the block only on receipt of ><ESCI 


resets screen to initial state as follows, 
erase the screen 

set cursor to "home" position 

set text mode 

clear all attributes 

set normal intensity for screen illumination 


e 2 @ 9 @ 
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 VIP7804. 


continued 
PRINTER» 


><esc [ op | : 


><esc[ 2p 
><esc [ 3p 


-><ESC [ 4p 


><esc [ 5 {ol1} p 


><esc [ 7np 


><esc [ <p 
><esc [ =cp 


causes data space to be printed in both transmission modes; 


areas to be eupe reese are selected by ><ESCs folo "printer" 
attribute; 
control codes and ednines are provided by the printer adapter 


terminates printing 


prints data stream without affecting screen or data space; 


control codes ><FFV, ><VTV, ><LFV and ><CRV are provided 
by the user, with the printer adapter inserting the a 
"time-fills" for the corresponding codes; 

><BSV and ><HTV must not be sent 


prints transparent data without affecting screen or data space; 
used for control codes other than ><FFV, ><VTV, ><LFV and 
><CRV ; 

"time-fills"' for control codes are provided in the form of 
><esc [ ?nnnp, where nnn is a 3-digit decimal value 


sets print mode, as follows, 
« if O, only unprotected fields are ulated 


e if 1, both protected and unprotected fields are printed 


specifies the number of copies to be peanecee where n is a 1 


digit decimal value 


indicates the end of data stream 

sets the control code to be used by the printer, where c is the 
graphic symbol, from O through ?, representing the following 
control code combinations, 


O start CR end CR 8 start CR end CR-FF 
1 CR-LF | CR 9 CR-LF CR-FF 
2 CR-FF CR $ CR-FF CR-FF 
3 CR-VT CR ; CR-VT CR-FF 
4 CR CR-LF < CR CR-VT 
5 CR-LF CR-LF = CR-LF CR-VT 
6 CR-FF CR-LF > CR-FF CR-VT 
7 CR-VT CR-LF ? CR-VT 
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CR-VT | 


SECTION VII 


QUEUE MAINTENANCE 


The queue maintenance utility is described in terms of 
e Input Data 
e Output Data 
» Commands 
e Executing QMAINT 


INPUT DATA 


Input data to QMAINT is in the form of QMAINT commands which are introduced 
e either on cards forming an input enclosure in a deck of JCL statements 


» or aS a subfile retrieved from a source library. 


If the QMAINT commands are used repeatedly for such functions as displaying or 
purging the contents of the queues systematically at the end of a communications 
session, they should be stored as a member of a librarye 


OUTPUT DATA 


Output data from QMAINT is in the form of print-out reports which are 


e SYSOUT report which provides the following 


- lists the QMAINT commands 

- lists the actions resulting from each command in the order listed in the 
run-time JCL | 

- indicates any errors detected during the execution of the QMAINT step 


» JOR, job occurrence report, which contains messages defining 
- system errors for which the job has aborted 
- user errors for which the job has halted abnormally. 
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came: 


| QuarNT picamedls are dealt with: in ‘terms of 


» Symbolic Convention 


-- -¢ Command Description 


Symbolic Convention 


The following mpeee define the QMAINT symbolic convention, 


Keywords for command names and parameters are written in capitals. in the 
texte 


The following symbols must not be specified in user-defined values, 


Slash | ( open parenthesis — 


V space 2 equals | - ) close parenthesis 


; semi-colon asterisk "' double quotation 


Utility-reserved keywords must not be specified as user-defined terms. 


A command can Span more than 1 card, for as long as the last card containing 
the end of the command is terminated by a semi-colon. 


Individual petansears of a ees be separated by COMMAS ; spaces, or 
commas and Spaces: 


Blank duets and "comment! cards are not processed. 


A user-supplied value exceeding the range of permitted yeIuee is disallowed 


_and flagged as an error. 
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Command Description 


Each command is described in terms of 
e definition, giving the purpose and function of the command 
o format of command, indicating mandatory, positional and optional parameters 


« description of parameters, describing the use and restrictions of each para- 
meter 


e command report, which lists all the actions performed by QMAINT as a result 
of the command execution. 


QMAINT 


Command Description 


jcoment | mettnttton | age 


defines a "comment"! and may appear anywhere in the sequence | 
of commands. 


| prints out, without altering, the contents of one, several 
or all of the queues defined within the network. 


| destroys all or part of the messages that are completely 
queued in a given queue. 


QSTATUS | lists the current Status and the generation parameters of 
| / one, several or all of the queues within the network. 


SEND | sends user-defined messages to the queues 


STATUS | continues or suspends the processing of QMAINT commands 
| when an error has previously occurred. 
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COMM 


| Definition “ 


The COMM command defines a comment and may appear anywhere in the Sequence of 
commands. 


Format of Command 


COMM "String" ; 


_ Description of Parameter 


string 
_- a character string enclosed within double quotation marks that must be 
opened and closed on the Same card. 


The string cannot be spawned on more than 1 card, ieee, the double Saceae ; 
tion mark closing the string must be on the same card as the double quot- 
ation mark opening the string. 3 | 


A maximum of 72 characters can be specified for each COMM command. 


If a comment is longer than 72 characters, the excess number of charact- 
ers must appear on the next COMM command. 


Command Report 


Only on command listing. 
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PRINT 


Definition 
The PRINT command is used to print out, without altering, the contents of one, 
several or all of the queues defined within the network. 


The contents of a queue is the set of messages that are completely queued, that 
is, not in the transitional state of being sent or received. 


The messages are printed out on the order that they would be received from the 
queue concerned by an application or by BTNS. 


Format of Command ~ 


queue-name-i [ » queue-name-2 soo queue-name-n | 


PRINT 3 
* 


queue-name 
- ranges from 1 throughi12 alphanumeric characters and is the external name of 


the queue as specified in the corresponding QUEUE command y see Network Gen- 


eration Manual. 


queue-name-1.. . queue-name-n 
- defines the list of queues and the order in which messages are to be print- 
ed oute 


*& 


- requests the print-out of the contents of all the queues defined within the 
given network. 


The order in which the messages are to be printed out will be the order in 
which the queves were declared at network generation. 
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PRINT 
continued — 


Command Report 


for each queue 


QUEUE NAME : 02 queue-name 


NUMBER OF COMPLETE MESSAGES : _ aaaaaa 
for each message 


MESSAGE NUMBER . bbbbbb 


OK 


_ MESSAGE STATUS NOTALL 


MESSAGE LENGTH : | | | ccccce 


MESSAGE CONTENTS : _ | text-of -message 


queue-name 
- ranges from 1 through 12 alphanumeric characters and is the external name of 
the queue as specified in the corresponding QUEUE command. 


aaaaaa | | 
- number of complete messages in the queue that have been printed. 


bbbbbb | 
- number of the message ranking in the queue. 


cecccc 
- length of the message in characters, 


OK | 
- complete text for the message has been printed. 


-NOTALL | 
- partial text for the message has been printed. 
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PURGE 


Definition 


The PURGE command destroys all or part of the messages that are completely 
queued in the referenced queue. 


Format of Command 


ALL 


PURGE queue-name 


NUMBMSG = nnnnn 


Description of Parameters 


queue -name 

- ranges from 1 through 12 alphanumeric characters and is the external name of 

the queue as specified in the corresponding QUEUE command, see Network Gen- 
eration Manual. 


ALL 
- specifies that all the messages present in the queue are to be destroyed. 


NUMBMSG 
~ specifies the number of messages in the queue to be destroyed. 


The number of messages ranges from 1 through 99999, 


Command Report 


QUEUE NAME : : queue-name 


NUMBER OF DELETED MESSAGES 3 aaaaaa 


queue-name | | | 
- ranges from 1 through12 alphanumeric characters and is the external name of 
the queue as specified in the corresponding QUEUE command. 


aaaaaa | | 
- number of messages destroyed, see ALL and NUMBMSG above. 
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es 


| Definition 
‘The QSTATUS comand lists the current status and the generation parameters of 


one, several or all of the queues within the network. 


7 Format of Command 


queue-name-1 [ » queue-name-2 occ queue-nane-n | 


QSTATUS 


% 


Description of Parameters 


‘queue-name : 

- ranges from 1 chveash4o stehemmente characters ana is the external name of 

‘the queue as specified in the carEcepoue ene. QUEUE command, see Network Gen- 
gration Manual. 


queue-name~1.«. queue-name-n | | 
~ defines the list of queues and the order in which their status and genera- 
tion parameters are to be listed. 


- | 
“se requests the listing of the current status and generation parameters of all 
the queues defined within the network. | 


| The order in which this information is listed will be the order in which 
the queues were declared at network generation. 
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QSTATUS 
continued 


Command Report 


for each queue 


QUEUE NAME : queue~name 
NUMBER OF COMPLETE MESSAGES) 3; aaaaaa 
NUMBER OF MESSAGES IN SEND PHASE 3: bbbbbb 
NUMBER OF MESSAGES IN RECEIVE PHASE =; _ eececce 
NUMBER OF BLOCKS ALLOCATED TO THIS QUEUE : dddddd 
NUMBER OF BLOCKS USED FOR THIS QUEUE : | eeeeee 
MAXIMUM NUMBER OF BLOCKS IN THE POOL :; £EFELE 
| NUMBER OF BLOCKS USED FROM THE POOL :; geeooe 


PROGRAM QUEUE ! : 
TERMINAL QUEUE 


DISK 

[ /BREAK ] 

[ /RESTART] 
f/tTwa} 


QUEUE ATTRIBUTES : et 


queue-name 
- ranges from 1 through 12 alphanumeric characters and is the external name of 
the queue as specified in the corresponding QUEUE command. 


aaaaaa | 
~ number of messages completely queued in the current States. 


- bbbbbb 


~ number of messages partially sent to the queue, that fey mere sees not ter- 
minated by either EMI or EGI. | 
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QsTATUS | 
| | continued - 


comand Report (contin 


- cccece 
 : number of messages partially eeveived from the queue. 


ddddad se EE 
- number of memory or disk blocks aviecaeed to the queue at network genera- 
tion through the respective parameters of the corresponding QUEUE command, 
« NUMBLK : number of memory blocks to be used as the memory queue pool 
e NUMREC : number of blocks to be used as the disk queue file. 


NUMBER OF BLOCKS ALLOCATED TO THIS QUEUE appears for memory queues not de- — 
fined with QCPOOL and for disk queues defined with NUMREC. 


 eeeece | | 
- number of used blocks among the '"dddddd" blocks reserved, see above. 


NUMBER OF BLOCKS USED FOR THIS QUEUE appears for memory queues not defined 
with eon and for disk queues defined with NUMREC. 


f£fffe 
- total number of memory bieces of the memory queue pool to Be shared by all 
queues qualified by the QCPOOL option in their respective QUEUE commands. — 
The total number of memory blocks is defined by the QGPOOL parameter of 
the GENCOM command. 


MAXIMUM NUMBER OF BLOCKS IN THE POOL appears for memory queues defined 
with QCPOOL and for disk queues not defined with NUMREC. 


— « Bgesss 
- number of used memory blocks from the "f£fffff" Siedke reserved, see above. 


_ NUMBER OF BLOCKS USED FROM THE POOL appears for memory queues defined with 
QCPOOL and for disk queues not defined with NUMREC. 


BREAK _ | | 
- applicable only to program-queues, see QUEUE command of Network Generation 
Manual. | 
CORE 


~ if NUMBLK or QCPOOL are specified in the QUEUE command. 


DISK 
- if NUMBLK and one do not appear in the QUEUE command. 


RESTART 
- applicable only to disk-queues, that is, program-queues. and terminal- 
queues, see QUEUE command of Network Generation Manual. 


TWA 
- applicable only to program-queues, see QUEUE command of Network eererar tou 
Manual. | 
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SEND 


Definition 


The SEND command sends user-defined messages to the queue. 


The text of the message to be sent immediately follows the command and can ap- - 
pear on several cards, each card spanning from column 1 through column 80. 


This function is used to simulate terminals and for debugging MAM applications. 


Format of Command 


SEND queue-name [ : ENDMSG="'end-of-message-string" || , LENGTH =nnnn | 3 


Description of Parameters 


queue-name 

- ranges from 1 through 12 alphanumeric characters and is the external name of — 

the queue as specified in the corresponding QUEUE command, see Network Gen- 
eration Manual. 


ENDMSG 
- ranges from 1 through 5 alphanumeric characters enclosed within double 
quotation marks and denotes the '"marker'' to be used to specify the end of 
the text of the message to be sent to the queue. 


If ENDMSG is omitted, the message text must be terminated by a //EOM card. 
Either ENDMSG or //EOM must be used. | 
LENGTH | 
- defines the length of the message in characters to be sent to the queue. 


If the length specified conflicts with the number of data cards after the 
command, a warning ERROR QC 0306 is displayed by QMAINT, see Appendix CG. 
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SEND 


continued © 


Command Report 


QUEUE NAME : _ — | - queue-name 


NOTALL 


MESSAGE STATUS | | } OK | 


MESSAGE LENGTH | | | aaaaaa 


MESSAGE CONTENTS : | ‘text -of-message 


queue-name 
- ranges from 1 through 12 alphanumeric characters and is the Sarernad name of 
the queue as specified in the corresponding QUEUE command. | 


aaaaaa 
oo name of characters in the message sent to the quent 


OK | 
- the ee of ietacears in the "text-of-message'"' matches the number speci- 
fied by "'aaaaaa". : 


NOTALL 
~ the number of characters in the "text-of-message" is less than the number 
specified by " aaaaaa"'. 


text -of-message 


- the text of the message sent to the queve is edited in a maximum of 110 
characters per line. | 
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SEND 
continued 


Example 1 
LENGTH not specified 


ADVISE TERMINAL SHUTDOWN 
SEND Q1,ENDMSG = "END"; 


In i.a and 1.b, the message to be sent to queve Ql] will be 80 characters, 
despite the fact that the actual message contains only 24 characters. 


| ADVISE TERMINAL SHUTDOWNV 56 spaces Vv 


This is because the LENGTH parameter in the SEND command was not specified 
and therefore the entire 80 columns of the card containing the message text 
after the SEND command is sent to the queue. 


Example 2 
LENGTH specified 


/ADVISE TERMINAL SHUTDOWN — | /ADVISE TERMINAL SHUTDOWN 
/SEND Q1, ENDMSG = "END", LENGTH = 24; /SEND Q1, LENGTH = 24; 


In 2.a and 2.b, the message to be sent to queue Qi will be 24 characters. 


| ADVISE. TERMINAL SHUTDOWN | 


Using this method of specifying the LENGTH parameter, the message can be 
"tailored"! exactly and no space is therefore wasted in the queue. 


STATUS 


Definition | 


ee ‘The STATUS command. continues or suspends the processing of QUAINT commands 
when an error has prexsousty:: occurred. 


Format of Command : 


STATUS 


Description of Parameters 


ONLY | | 
- this is the default, whereby the commands are only executed pEeveeee that 
no error has occurred, 


EVEN 
- only the following command is executed when an error has occurred. 


RESET 
- resets the error count to zero. 


Command Report 


Only on command listing. 
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EXECUTING QMAINT 


Executing QMAINT is dealt with in terms of, 
» Run-time Prerequisites 


o Run-time JCL 


Run-time Prerequisites 


All the following prerequisites must be met to execute QMAINT, namely, 


e A previous CNC session describing all the queues referenced by the QMAINT 
commands must have been successfully run. 


e Each program-queue referenced by a QMAINT command must be available, namely, 
- it must not be allocated to any application in IN, INOUT or OUT modes 
- it must not have any terminals connected to it 


e Each terminal-queue referenced by a QMAINT command must be available, that 
is, the queue must not be currently allocated to any application 


- either explicitly through a $QASSIGN statement 


-- or implicitly through the terminal connection to the application 


Run-time JCL 


The syntax for QMAINT run-time JCL is as follows, 


e STEP statement 


- H_QMAINT is the system load-module in the system load-module library 
called SYS.HLMLIB and must be specified as shown. 


e ASSIGN statement 


- H_CR is the system-reserved internal-file-name for the file containing 
the QMAINT commands, either as an input enclosure or as a source library 
member, and must be specified as showne 


In the "Example of QMAINT Execution", 


« the job QDISP performs actions on the queues specified within the current 
network 


» the maintenance actions to be performed are described by the QMAINT commands 
in the input enclosure. 


For detailed explanation, see Appendix Be 
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QMAINT 
Run-time J CL _ 


commands retrieved 
from an input enclosure 


$JOB job-name , USER=user-name > PROJECT = project-name ; 


STEP H QMAINT , SYS. HLMLIB ; 
ASSIGN H_CR, *input -enclosure-name ; 
ENDSTEP ; 
$INPUT input-enclosure-name z TYPE =DATASSF | ; 
QMA INT 
commands 
$ENDINPUT ; 


| $ENDJOB ; 


commands retrieved 
from a source library member 


$JOB job-name , USER=user-name , PROJECT = project-name ; 
STEP H_QMAINT , SYS. HLMLIB ; 


ASSIGN H_CR, external-file-name , SUBFILE =member-name , 


DEVCLASS =device-class-name , MEDIA =media-name 5 


ENDSTEP ; 


SENDJOB ; 


QMAINT Run-time JCL 
(continued) 


QMAINT Execution 


$JOB QDISP , USER=UNAME , PROJECT =WAGE ; 
STEP H_QMAINT , SYS. HLMLIB ; | 
ASSIGN H_CR, *QINP; 

ENDSTEP ; 


$INPUT QINP ; 


COMM "SPECIFIED QUEUES ARE Q1,Q2,Q3,Q4"'; 

COMM "DISPLAY STATUS OF ALL THE QUEUES" ; 

QSTATUS * 3 | 
COMM "PURGE Qi (ALL MESSAGES) AND Q2 (ONLY 5 MESSAGES)"'; 
PURGE Q1, ALL; 

PURGE Q2 , NUMBMSG=5 ; 

COMM "CONTINUE EVEN IF WRONG RESULT FROM PURGE'"'; 
STATUS EVEN 3 | | 

COMM "PRINT CONTENTS OF QUEUE Q3"'; 

PRINT Q3;3 

COMM "SEND ONE 17 CHARACTER MESSAGE TO Q4"'; 

SEND Q4 , ENDMSG = "ENDMS" , LENGTH = 17 ; 

TERMINAL TO LOGON | 

ENDMS 


$ENDINPUT 3 


$ENDJOB 5 
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SECTION VIII ne ee 


DYNAMICS OF COMMUNICATIONS 


Events occurring during a communications session are governed both by the user 


and 


The 


e 


the system. 


determining factors are, 

Execution chronology of the software components 
Levels of simultaneity for communications 
Optimum priorities for the software components 


Data flow during message exchange 


Allocating-memory reSources. 


EXECUTION CHRONOLOGY OF THE SOFTWARE COMPONENTS 


Before any communications session can take place, the network environment must 
first be created, using the CNC utility. 


The network is successfully created if no errors occur during generation 


BINS and FNPS can be started to allow VCAM subsystems to execute. QMON can then 
be started to allow, in turn, MCS applications to execute. QMON runs as a sepa- 
rate service job from both BINS and FNPS. 


Whenever backing store is destroyed, the fallowing actions must be performed, 


e 


@ 


the CNC utility must be rerun 


the option MAM=YES or MAM=REFORMAT must be specified at system initializa- 
tion if disk queueing is involved (MAM=YES is the default). 


Backing store is destroyed for one of following reasons, 


@ 


either through a disk failure 


or when the CLEAN option is specified at restart. 


ee rea oe eS 


Further constraints in determining the order in which the software components 
are executed, are 


the CNC utility cannot be run when any communications component is current ly 
executing, and vice versa | : 


BINS cannot be run when another occurrence of BINS is currently executing 


an MCS application step with a $QASSIGN statement specifying a queue current- 
ly allocated to another step cannot be run. 


Pulls. to comp ly with any of the contraints listed on She previous page, will 
lead to a ener abort. : | 


Up to 4 occurrences of the FNPS service can be started to execute simultaneous ]y. 


Each occurrence is identified by its associated "fnp-name" declared in the FNP 
command of the CNC generation. A maximum of 4 FNP commands can be So declared. 


LEVELS OF SIMULTANEITY FOR COMMUNICATIONS 


Within the limits of operability as previously defined, communications components 
can be started and terminated for as long as the maximum system multiprogramming 


level is not exceeded. 


The following occurrences illustrate the levels of simultaneity for a communica- 
tions session over the BINS/URP secondary network, 


1. 


26 


360 


4, 


De 


6. 


To 


8. 


A data collection MCS application DATCOLL starts. 
Its function is to empty disk input queues filled by BTNS during a prev- 
ious session. 


Number of simultaneities : 1 


A data distribution MCS application DATDIST starts. 
Its function is to distribute to output queues, messages generated by a 
batch program during a previous session 


Number of simultaneities : 2 


A TDS job is started. 


Connections from the network are not yet possible, although TDS is avail- 
able to batch entries. 


Number of simultaneities : 3 


A TDS batch entry starts. 
The batch entry requests connection to TDS to execute file updates. 


Number of simultaneities : 4 


DATDIST has completed distributing all messages to output queues and termi- 
nateSe 


Number of simultaneities : 3 


A file enquiry MCS application FILEINQ starts. 
The application awaits requests to be received into its input queues. 


Number of simultaneities : 4 


BINS now starts, which results in the following, 


the BINS/URP secondary network is initialized through the "ST gencom- 
name" system console command 


a 


QMON is then activated through the "ST QMON'' network control command. 


- log-on requests from terminals to connect to defined input queues and 
TDS are accepted 


- the distribution of data enqueued by DATDIST to the terminals connected 
to input queues is now started. 


Number of Ssimultaneities : 4 


Although BINS and QMON run as Separate service jobs, they do not eccuny any 
level of simultaneity- 


DATCOLL has completed emptying the disk queues and terminates. 


Number of simultaneities : 3 


* 


—_, The TDS batch entry, see step 4, has ere its ‘files and terminates. 
_ Number of simultaneities : 2 | . 
10. TDS now terminates as it is no longer vemutrads , 
Number of simultaneities : 1 | | | | - | | 
11. FILEINQ has accepted all enquiries from the input queues and terminates. 
| Number of simultaneities 20 | | - | 


12. BINS is. retained in the system to fill the disk queues. 
This operation would be continued in a following session by erereine up 
the application DATCOLL, see step 1. 


a Number of simultaneities : O 
13. A shutdown is issued. | 


BINS terminates and the communications session ends. 
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OPTIMUM PRIORITIES FOR SOFTWARE COMPONENTS 


In order to maintain efficient response times, appropriate dispatching priorities 
for the various communications components must be selected. 


Batch jobs are given low priorities as they are not subject to real-time con- 

Straints. 

The user specifies a job class which determines the following for the job: 

e its scheduling priority 

« its dispatching priority 

» its associated level of multiprogramming, being the number of jobs executable 
at one time. 

An example of such considerations is the following situation: 


e CNC and QMAINT utilities, being normal batch jobs, are not subject to any res- 
ponse times and can therefore be executed as jobs of class, say, P 


However, an MCS application step and the TDS service, when executed concurrent- 
ly, that is, both being available in the system at the same time, should have 
the same dispatching priority. ; 


While the programmer has no control over VCAM queues for the TDS service, the 


transactions themselves can be written in such a way as to optimize multitask- 


ing, see TDS Documentation 


For the MCS application, in order not to degrade system performance, unnecessa- 

ry scanning of the program-queue should be avoided, examples of such indiscrim- 

nate scanning are 

- a RECEIVE (H_RECEIVE) with "no data" 

- an ACCEPT (H_MSGCNT) instead of building a suitable queue structure and using 
one of the scanning techniques recommended. 


By specifying J as the job class for the TDS service and H for that of the MCS 
application, the scheduling and execution priorities are 6 and O, respectively. 


These values are the recommended defaults for the DPS 7 installation. 


in this case, the level of multiprogramming for the job classes specified for 
the TDS service and the MCS application is 1, however, this value can be modi- 
fied by the MS system console command, see System Operator's Guide. 


@ 


For a description of the use of job class, see System Administrator's Manual. 


Message exchange follows a prescribed path and involves the following types, 
» exchange between an MCS application and a terminal using -a memory queve 
« exchange between an MCS application and a terminal using a disk queue 


- exchange between a VCAM subsystem (communications service) and a terminal. 
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7 Example of Exchange 
Between an MCS Application and a Terminal | 
_ Using a Memory Queue 


— MCS 
application 


1. When the line is polled, the terminal sends a message which is stored in 
the BINS buffer pool. | 
_ BINS dynamically allocates buffer units to contain the stole: message. 


2e The message is sent by BINS to QMON via VCAM. 


3. Control characters and marks are translated by QMON according to termi-- 
nal type and data format for input. 


4 QMON stores the message in the memory input queue to which the terminal 
is connected by issuing a call to the MCS "send" procedure. 
5. When the application issues a "receive" to the symbolic input queue, the 
mesSage or a part of it, is moved into the application's input work area. 
As many "receive's" as necessary are issued to collect the whole message. 


6. When the message is to be sent to the terminal, the application issues a 
"send" to the symbolic output queue. 
The message is transferred from the application's output work area to the 
memory output queue associated with the terminal. 


7. When the output request. is located, QMON issues a call to the MCS "rec- 
eive" procedure to store the message in the QMON area. 


8. Control characters and marks are translated by QMON Sc to termi- 
nal type and data format for outpute 


9. The message is sent by QMON to BINS via VCAM | | 
10. The message is transferred from the BINS buffer pool to the terminal. 


Example of Exchange 


Bétween an MCS Application and a Terminal 
Using a Disk Queue 


MCS 
~j application| 


buffer 
pool 


| output 
work L 
area jp 


output 
| buffer 


output 
work 
area 


The example shows input from the terminal to the MCS application. 
The procedure is identical in reverse from the application to the terminal. 


1. When the line is polled, the terminal sends a message which is stored in 
the BINS buffer pool. 
BINS dynamically allocates buffer units to contain Ene ne enon eeee 


2. The message is sent by BINS to QMON via VCAM. 


3. Control characters and marks are translated by QMON according to termi- 
nal type and data format for input. | 


4, When QMON issues a call to the MCS "send" procedure to store the message 
ain the disk input queve to which the terminal is connected, the follow- 
ing events take place, 
» the message is first moved to the disk I/O buffer pool 
eo the message is then written to the disk queue file. : 
Disk access for QMON is asynchronous which means that QMON does not have 
to wait for the completion of an I/0 operation ice 


5. When the application issues a "receive" to the symbolic input queue, the 
following events occur, | 
e the message is read from the disk queue file into the disk 1/0 buffer | 
pool 
e the message is then moved into the application's input work area 
Disk access for the application is synchronous which means that the appli- 
cation must wait for the completion of an I/0 operation. 


Example of Exchange 
Between a VCAM Subsystem and a Terminal 


~ VCAM — 
subsystem 


GCOS Communi cat ions Services, collectively termed VCAM subsystems, are, 
- RBF6/FTIF6, Remote Batch Facility & File. Transfer Facility, Mini6-DPS 7 
- DJP/DFT, Distributed Job Processing and DSA File Transfer, DPS 7- porns? vy 
.- IOF, Interactive Operator Facility 
- TDS, Transaction Driven Subsystem 
- CARDLESS, known to the system as READER 


+ TILS, Transactional and Interactive Load Simulator 


ae EEe On-Line Tests and perenne 


1. 


26 
36 


4. 


De 


A message is sent by the terminal to bs stored in the ‘BINS buffer pool, 
occupying aS many buffer units as required. 


The message is moved to the work area designated by the VCAM subsystem 


The message is handled by the VCAM subsystem 
In the case of TDS, for example, the message activates or is processed by 
a transaction program or a set of transaction processing routines. 


A reply to the terminal is moved from the VCAM subsystem work area to the 
output buffer pool. 


The AME SEREE is transferred from the BINS buffer pool to the terminal. 
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ALLOCATING MEMORY RESOURCES 


Multiprogramming in a virtual memory environment may lead to an overload situa- 
tion where several applications compete for memory resources. 


The 


@ 


The 


The 


effects on the communications session are 


that the segments of its components not currently executing may be swapped 
with batch programs 


that these segments, when needed to process a message on arrival, must be 
reloaded, causing 


- a tremendous increase in system overhead 
- a considerable increase in response time 
- a degradation of overall throughput. 
problems to be solved are 
avoiding memory overload of the system: 


The sum of the "working-sets" of applications executing concurrently must 
not exceed the physical memory size available. 


guaranteeing the minimum memory resources: 


In order to enSure rapid "turn-around", segments of communications compo- 
nents needed to process specific data, must be retained in memory even if 
inactive over long periods. 


solutions are 
using the SIZE statement: 


‘The SIZE statement declares the ‘working-set" of the application for the 
purpose of controlled scheduling to avoid memory overload. 


uSing the MAXMEM and MINMEM parameters of the STEP statement, as follows, 


MAXMEM: 
Used for tuning the ipoviage -set'' and should be discontinued when the 
optimal size has been determined. 
This facility ensures that 


- the amount of memory allocated will never be less than the DWS spe- 
cified in the SIZE statement 


- the system will not attempt to execute the step if the amount of 
physical memory available is not greater than or equal to the DWS, 
even if the step could be run on less. 

The step does not benefit by the gradual release of memory resources 
as the system load decreases. 


MINMEM: 
Used after the optimal DWS has been determined to allocate permanently 
to the step a memory resource equal to the DWS whatever the load of the 
system may be. 
This facility is used when "turn-around" times for the communications 
session are slow, indicating that the components needed for processing 
are absent in memory. By guaranteeing 'minimum-memory" requirements, all 


communications components needed for the session will be present in me- 


mory: until terminatione 
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oe “using the PMM eengélé command: 


In order to ensure the presence of system Fmekiese,: the PMM command can 
_be used to "lock" these segments co eee so that. Epete become Permeaneees 
ly availablew yA os 


Allocating memory resources is dealt with in regard to. 
. MCS applications | 
« MAM and VCAM 
7 « BINS (which ipequdes 175), FNPS and baci 


Allocating Memory to MCS Applications 
The way to determine mow Memory resources are to be allocated to MCS applications 
is as follows, 

» establishing the size of the DwWS 


° guaranteeing memory by declaring the DWS as the minimum resource required, 


ESTABLISHING THE DWS SIZE 


The first time that the step is exaeiiee the dws-value specified for the SIZE 
Statement is calculated from the linkage listing of the application and declared © 
aS MAXMEM in the STEP statement. 


The JOR listing at the end of the ae step will eee the number of missing 
Segments, if any. 


The general rule in tailoring the dws-value specified in units of K bytes is 


- if few missing segments are indicated, a smaller dws-value can be specified 
until such a time when an increase in missing segments occurs 


« if many missing Segments are indicated, a proportionately higher dws-value 
Should be specified, until such time that the first condition is reached. 


Successive executions of the job step will ultimately give an optimum dws-value. 


GUARANTEEING MEMORY 


The "optimum" dws-value is then specified for the SIZE statement and declared 
as MINMEM in the STEP statement. 


By this means, the step is "guaranteed" the minimum memory reSource before it is 
started by the system 


run-time JCL for DWS 


omen : 


MINMEM 
SIZE dws-value eee 


be oa : | STEP eece { 
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Allocating Memory to MAM and VCAM 


Both MAM and VCAM are system functions which can be "locked" in memory by the 
PMM console command, .the format and function being as follows, 


o PMM VCAM : VCAM segments are "locked"! 
» PMM MAMM : MAM segments managing memory queues are "locked" 
e PMM MAMD : MAM Segments managing disk queues are "locked". 


After the PMM command specifying the function to be "locked'' is issued, the 
function remains in memory until the CMM command specifying the function is iss- 
ued making the function eligible for swapping out of memory. 


Allocating Memory to BINS, FNPS and QMON 


All three service jobs run automatically under MINMEM when initialized by the ST 
network control command. 


They communicate to the system Ene memory Size needed according to the configu- 
ration presente 


No user intervention is required to ensure the presence of BINS, FNPS and QMON. 
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APPENDIX A 


MCS. APPLICATION EXAMPLE 


This is a teSt program for the "two-way-alternate" option, in which the applica- 
tion sends the message "ENTER M OR G'"' to the console operator. 


The console operator, on receipt of this message, can then reply 


« M, in which case the application, by delimiting transmission with EMI, re- 
tains the turn to transmit | 


e G, in which case the application delimits transmission with EGI, thereby 
giving the turn to transmit to the operator 


o E, in which case the application then terminates. 


This application is part of a test package for communications software, and 
Serves aS an example of the user interface with MCS. 


A detailed explanation of the TWA option used with interactive applications is 
given on page 2-16. | 
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_ Mes Applicat i on » Examp 1 e 


in 
MCS COBOL 


IDENTIFICATION DIVISION. 

- PROGRAM-ID. TEST. TWA. 
ENVIRONMENT DIVISION. 
CONFIGURATION SECTION. 
SOURCE-COMPUTER. LEVEL-64. 
-OBJECT-COMPUTER. LEVEL-64. 


DATA DIVISION. 


_WORKING-STORAGE SECTION. 
O01 ACOI1REPLY PIC X. 


01 MSGEMI PIC X(90) VALUE ALL "EMI". 
01 MSGEGI PIC X(90) VALUE ALL "EGI". 
01 BUFIN — PIG X(2000)._ 


COMMUNICATION SECTION. 
CD CDIN FOR INPUT QUEUE CDIN-QUEUE-NAME. 
CD CDOUT FOR OUTPUT. 
7 ol CDOUT-SPECIF. 
O02 CDOUT-DESTINATION-COUNT PIC 9(4) VALUE i. 


O02 CDOUT-TEXT-LENGTH | PIC 9(4) VALUE 90. 

O02 FILLER PIC XX. 

O02 FILLER PIC X. 

02 CDOUT-DESTINATION PIG X(12) VALUE "INTQOUT''. 
PROCEDURE DIVISION. | 


BEGIN. 
ENABLE INPUT CDIN KEY '"PASW"' 
ENABLE OUTPUT CDOUT KEY '"PASW"! 
MOVE "INTQIN' TO CDIN-QUEUE-NAME . 


DISPLAY “ENTER M OR G!' UPON CONSOLE 
ACCEPT ACOIREPLY FROM CONSOLE 


IF ACO1REPLY = '™'' 
SEND CDOUT FROM MSGEMI WITH EMI. 


IF ACO1REPLY = NG" : 
MOVE 90 TO CDOUT-TEXT-LENGTH 
SEND CDOUT FROM MSGEGI WITH EGI. 


IF ACOLREPLY="E" 
GO TO TERM 
ELSE GO TO LOOP. 


RECEIVE CDIN MESSAGE INTO BUFIN 
STOP RUN. | 


end of test for the two-way-alternate option 


A-02 


MCS Application Example 


TEST TWA : PROC ; 


/* DECLARATIONS */ 
DCL H_BUFIN CHAR( 2000) ; 
DCL A PO4CDOUT PTR; 
DCL A POSCDIN PTR; 
DCL A PO4MESI PTR; 
DCL A _PO4MESO PTR; 
DCL MSGEMI CHAR(90) STATIC INIT((30)"EMI") ; 
DCL MSGEGI CHAR(90) STATIC INIT((30)"EGI") ; 
DCL A_CO1REPLY CHAR(1) STATIC; 
DCL A_F15MOP FIXED BIN(15) STATIC INIT(12) ; 
DCL A_Ci2MSG CHAR(12) STATIC INIT("ENTER M OR G") 3 
DCL A_Fi5MXL FIXED BIN(15) STATIC INIT(1) ; 


$H_CD INPUT , PREFIX='CDIN_' , ATTRIB='STATIC INTERNAL’) ; 
$H_CD OUTPUT , PREFIX='CDOUT_' , ATTRIB='STATIC INTERNAL’ ; 


/* PROCESS */ 


BEGIN ; 
A_PO4CDOUT = ADDR(CDOUT_OUTPUT_CD) ; 
A _PO4CDIN=ADDR(CDIN_INPUT_CD) ; 
A_PO4MESI = ADDR(H_BUFIN) ; 
CDOUT_DESTINATION COUNT = 1; 
CDOUT_QUEUE_NAME(1) = "INTQOUT" ; 
CDIN_QUEUE_NAME(1) = "INTQIN" ; 


$H_ENABLE A PO4CDIN , INPUT ; 
$H_ENABLE A_PO4CDOUT , OUTPUT ; 


LOOP 3 
$H_ SENDOR REPLY =A _COIREPLY , MAXLEN=A_F1I5MXL , MESSAGE =A_Ci2MSG , 
LENGTH =A _F15MOP , MATIN 3 | 
IF A _COLREPLY ="! THEN BEGIN 3; 
A PO4MESO = = ADDR(MSGEMI) 3 
CDOUT_TEXT_ LENGTH = 90 3 
$H_ SEND A “PO4CDOUT , INADDR = A_PO4MESO , ENDCHAR = EMI ; 
END 3 
IF A_COLREPLY = '"'G" THEN BEGIN 35 
A_PO4MESO = ADDR(MSGEGT) 3 
CDOUT _TEXT_LENGTH = 90 5 
$H_ SEND A POACDOUT , INADDR =A_PO4MESO , ENDCHAR=EGI ; 


END ; | 

IF A_COIREPLY="E" THEN GOTO TERM; ELSE GOTO LOOP; 
TERM 3 

$H_ RECEIVE A_PO4CDIN , OUTADDR=A_PO4MESI , LENGTH = 200 ; 

END ; 


END TEST_TWA 3 
end of test for the two-way-alternate option. 
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APPENDIX B 


QMAINT SYSOUT REPORT 


The results of running the QMAINT utility are, 

e QMAINT error messages, see Appendix C 

e the QMAINT sysout report. 
The purpose of the report is to enable the user to ascertain that the mainte- 
nance functions on the contents of his memory and disk queues are correctly car- 
ried out. 
The structure of the QMAINT sysout report is as follows, 


e the header line, which appears as the first line of the report and has the 
standard format for any GCOS’ utility 


« the header banner 
eo run-time JCL, containing the listing of QMAINT commands provided by the user 


» execution report, providing a detailed report of each QMAINT command in the 
order listed in the run-time JCL, and any error messages as a result of 
QMAINT execution 7 


e error Summary, being a statistical report for each Severity. 


In the following example, QMAINT executes actions on 
© Q1, Q5 and Q6, which are disk queues 


» Q2 and Q3, which are memory queues. 
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Header Line 


QO X15.1 TEST TELE COUNT1 ADMIN 15:43:10 AUG 9, 1980 [PAGE 1] 
{page nn in 
the report 


date of execution 


time of execution 


project-name from $JOB 
billing-name from $JOB 


user-name from $JOB 


job-name from $JOB_ 


job and step-number of execution 


name and version of QMAINT utility 


Header Banner | 


kk Rk RK KKK * See ae RAK KR KR KR KKK KKK EK kek RK 
GCOS L64 | | 
QMAINT VERSION: 20,00 AUG 9, 1980 
_ EXECUTION REPORT a _ 
ee ee ee ee 


QMAINT Run-time JCL 


Execution Report 


see pages following 


Error Summary 


_ ERROR QCO314 SEVERITY OO TOTAL NUMBER OF ERRORS : " OO00000000 
* ERROR QCO315 SEVERITY O01 NUMBER OF ERRORS OF SEVERITY 1: OOQOQ000000 

* * ERROR QCO316 SEVERITY O2 NUMBER OF ERRORS OF SEVERITY 2: OOOQQ000000 
* * * ERROR QCO317 SEVERITY 03 NUMBER OF ERRORS OF SEVERITY 3: 0000000000 


£ ap 
ore 


QMAINT Run-time JCL 


$JOB TEST , USER=TELE , PROJECT = ADMIN , BILLING = COUNT1 ; 
STEP H_QMAINT , SYS. HLMLIB ; 

ASSIGN H_CR, * QMAINT ; 

ENDSTEP ; 

$INPUT QMAINT , TYPE = DATASSF ; 

SEND Qi , ENDMSG='"'//FIN" , LENGTH = 160 ; 


; AAAAAAAAAI1i 
AAAAAAAAAAAAAAAA sample printout AAAAAAAAAAAAAA 
AAAAAAAAAAAAAA of contents AAAAAAAAAAAAA111 
AAAASAAAAAAA AAAAAAAAAAAAAAAILIL1 
//FIN 
SEND Q1 , LENGTH = 1603 
BBBBBBBBBBBBBBBBBB | BBBBBBBBBBB2 
BBBBBBBBBBBBBBBB Sample printout | BBBBBBBBBBBBB2 
BBBBBBBBBBBBBB of contents _ BBBBBBBBBBBBBBBB 
BBBBBBBBBBBB BBBBBBBBBBBBBBBBBB 
//EOM 
QSTATUS * 3 
PRINT * 3 
PRINT Qi 3 
PRINT Q43 
PRINT Q5 3 

PRINT Q6 3 


PURGE Qi , NUMBMSG= i; 
PURGE Qi , NUMBMSG=1; 
QSTATUS * 3 

PURGE Q2 , ALL ; 
QSTATUS Qi , Q2;3 

PRINT Qi, Q3, Q5, Q63 
PURGE Qi , NUMBMSG = 1 3 
PURGE Q3 , ALL 3 

PURGE Q4 , NUMBMSG = 3 3 
PRINT Q3 3 

$ENDINPUT 3 

$ENDJOB 3 
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 QMAINT 


. Execution Report. 


SEND Ql, ENDMSG="//FIN" , LENGTH = 160; 


QUEUE NAME ;: 

MESSAGE STATUS : 
MESSAGE LENGTH : 
MESSAGE CONTENTS 


AAAAAAAAAAAAAAAA 


AAAAAAAAAAAAA 
AAAAAAAAAA 
AAAAAAA 


SEND Q1 , LENGTH = 160; 


QUEUE NAME : 
MESSAGE STATUS : 
MESSAGE LENGTH 


MESSAGE CONTENTS 


BBBBBBBBBBBBBBBB 
BBBBBBBBBBBBB 
BBBBBBBBBB 
BBBBBBB 


sample printout  AAAAAAAAAA 
of contents MAAAAAAAAA111 


Qi 
OK 
000160 


- BBBBBB2 


sample printout - BBBBBBBBB2 
Cad 

of contents BBBBBBBBBBBBB 

BBBBBBBBBBBBBBBB 
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QSTATUS *3 


QUEUE NAME : 

NUMBER OF COMPLETE MESSAGES :; 

NUMBER OF MESSAGES IN SEND PHASE =: 
NUMBER OF MESSAGES IN RECEIVE PHASE : 
MAXIMUM NUMBER OF BLOCKS IN POOL :; 
NUMBER OF BLOCKS USED FROM POOL :; 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : 


QUEUE NAME : 

NUMBER OF COMPLETE MESSAGES : 

NUMBER OF MESSAGES IN SEND PHASE : 
NUMBER OF MESSAGES IN RECEIVE PHASE :; 
NUMBER OF BLOCKS ALLOCATED TO THIS QUEUE 
NUMBER OF BLOCKS USED FOR THIS QUEUE : 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : 


QUEUE NAME : 

NUMBER OF COMPLETE MESSAGES ;: 

NUMBER OF MESSAGES IN SEND PHASE : 
NUMBER OF MESSAGES IN RECEIVE PHASE :; 
NUMBER OF BLOCKS ALLOCATED TO THIS QUEUE 
NUMBER OF BLOCKS USED FOR THIS QUEUE =: 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : 


QUEUE NAME =: | 

NUMBER OF COMPLETE MESSAGES : 

NUMBER OF MESSAGES IN SEND PHASE :; 
NUMBER OF MESSAGES IN RECEIVE PHASE ; 
MAXIMUM NUMBER OF BLOCKS IN POOL ;: 
NUMBER OF BLOCKS USED FROM POOL : 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : 


QUEUE NAME : 

NUMBER OF COMPLETE MESSAGES 3; 

NUMBER OF MESSAGES IN SEND PHASE ss 3 
NUMBER OF MESSAGES IN RECEIVE PHASE ; 
MAXIMUM NUMBER OF BLOCKS IN POOL :; 
NUMBER OF BLOCKS USED FROM POOL :; 
PROGRAM QUEUE 

QUEUE ATTRIBUTES ; 


QUEUE NAME :; 

_ NUMBER OF COMPLETE MESSAGES ; 
NUMBER OF MESSAGES IN SEND PHASE 3: 
NUMBER OF MESSAGES IN RECEIVE PHASE 
MAXIMUM NUMBER OF BLOCKS IN POOL : 
NUMBER OF BLOCKS USED FROM POOL :; 
PROGRAM QUEUE 

QUEUE ATTRIBUTES ;: 


eo 
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Q1 
000002 


000000 


000000 
032767 
000000 


DISK 


Q2 

000000 
000000 
Q00000 
000040 
000000 


CORE 


Q3 

000000 
000000 
000000 
000040 
000000 


CORE 
Q4 
000000 
000000 
000000 
032767 
000000 


DISK 
Q5 
000000 
000000 
000000 


032767 
000000 


DISK 


Q6 
000000 
000000 
000000 
032767 
000000 


DISK _ 


PRINT *5 


PRINT Q1 ; 


QUEUE NAME : ee ee 9 ae 
NUMBER OF COMPLETE MESSAGES 2 i. 4 000002 
MESSAGE NUMBER: ers 000001 
MESSAGE STATUS: OK 
MESSAGE LENGTH :; 000160 

- . MESSAGE CONTENTS : | os, | 
_ AAAAAAAAAAAAAAAA :  s ABBAII1 
 AAAAAAAAAAAAA sample printout __ | AAAAAAAAAA 
AAAAAAAAAA of contents AAAAAAAAAA111 
AAAAAAA | AAAAAAAAAAAAAI11 
MESSAGE NUMBER :; 900002 
MESSAGE STATUS : OK 

MESSAGE LENGTH : | 000160 
MESSAGE CONTENTS : 

- BBBBBBBBBBBBBBBB BBBBBB2 
BBBBBBBBBBBBB sample printout , BBBBBBBBB2 
BBBBBBBBBB of contents | BBBBBBBBBBBBB 
BBBBBBB BBBBBBBBBBBBBBBB 

QUEUE NAME : | Q2 
NUMBER OF COMPLETE MESSAGES : | 000000 
QUEUE NAME : | 7 | Q3 
NUMBER OF COMPLETE MESSAGES : | , ~ 000000 
QUEUE NAME : | Q4 
NUMBER OF COMPLETE MESSAGES > | 000000 
QUEUE NAME : | | Q5 
NUMBER OF COMPLETE MESSAGES : : 000000 
QUEUE NAME : 06 
NUMBER OF COMPLETE MESSAGES : 000000 
QUEUE NAME : | | oe Ql 
NUMBER OF COMPLETE MESSAGES : 000002 
MESSAGE NUMBER : 000001 

MESSAGE STATUS : OK 
MESSAGE LENGTH : 000160 
MESSAGE CONTENTS : | 
AAAAAAAAAAAAAAAA AAAA111 
AAAAAAAAAAAAA sample printout | ; | AAAAAAAAAA 
AAAAAAAAAA 7 of contents AAAAAAAAAA111 
AAAAAAA AAAAAAAAAAAAA111 
MESSAGE NUMBER : 000002 
MESSAGE STATUS : OK 
MESSAGE LENGTH : 000160 
MESSAGE CONTENTS : 

BBBBBBBBBBBBBBBB BBBBBB2 
BBBBBBBBBBBBB sample printout BBBBBBBBB2 
BBBBBBBBBB of contents | BBBBBBBBBBBBB 
BBBBBBB | i BBBBBBBBBBBBBBBB 
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QMAINT Execution Report 


(continued) 


PRINT Q4; 
QUEUE NAME : Q4 
NUMBER OF COMPLETE MESSAGES : 000000 
PRINT Q5; 
QUEUE NAME : : Q5 
NUMBER OF COMPLETE MESSAGES : 000000 
PRINT Q6 3 
QUEUE NAME; | Q6 
NUMBER OF COMPLETE MESSAGES : 000000 


PURGE Q1 , NUMBMSG=1 ; 
QUEUE NAME ; Qi 
NUMBER OF DELETED MESSAGES ; ~  ©00001 
PURGE Qi , NUMBMSG = 1 3 


QUEUE NAME : | Ql 
NUMBER OF DELETED MESSAGES: 000001 


Se 
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-QSTATUS *; _ 


QUEUE NAME 

NUMBER OF COMPLETE MESSAGES : 

NUMBER OF MESSAGES IN SEND PHASE : 
NUMBER OF MESSAGES IN RECEIVE PHASE : 
MAXIMUM NUMBER OF BLOCKS IN POOL : 
NUMBER OF BLOCKS USED FROM POOL : 
PROGRAM QUEUE : 
QUEUE ATTRIBUTES : 


QUEUE NAME - 

NUMBER OF COMPLETE MESSAGES : 

NUMBER OF MESSAGES IN SEND PHASE : 
NUMBER OF MESSAGES IN RECEIVE PHASE : 
NUMBER OF BLOCKS ALLOCATED TO THIS QUEUE 
NUMBER OF BLOCKS USED FOR THIS QUEUE : 
PROGRAM QUEUE | 

QUEUE ATTRIBUTES : 


QUEUE NAME : | | 
NUMBER OF COMPLETE MESSAGES: 
NUMBER OF MESSAGES IN SEND PHASE : 


_ NUMBER OF MESSAGES IN RECEIVE PHASE : 
NUMBER OF BLOCKS ALLOCATED TO THIS QUEUE — 


NUMBER OF BLOCKS USED FOR THIS QUEUE : 
PROGRAM QUEUE 
QUEUE ATTRIBUTES : 


QUEUE NAME : | 

NUMBER OF COMPLETE MESSAGES: 

NUMBER OF MESSAGES IN SEND PHASE : 
NUMBER OF MESSAGES IN RECEIVE PHASE : 
MAXIMUM NUMBER OF BLOCKS IN POOL : 
NUMBER OF BLOCKS USED FROM POOL : 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : 


QUEUE NAME : 

NUMBER OF COMPLETE MESSAGES : 

NUMBER OF MESSAGES IN SEND PHASE : 
NUMBER OF MESSAGES IN RECEIVE PHASE : 
MAXIMUM NUMBER OF BLOCKS IN POOL : 
NUMBER OF BLOCKS USED FROM POOL : 
PROGRAM QUEUE | | 
QUEUE ATTRIBUTES : 


QUEUE NAME : | 

NUMBER OF COMPLETE MESSAGES : 
NUMBER OF MESSAGES IN SEND PHASE : 
NUMBER OF MESSAGES IN RECEIVE PHASE 
MAXIMUM NUMBER OF BLOCKS IN POOL : 
- NUMBER OF BLOCKS USED FROM POOL : 
PROGRAM QUEUE - 
QUEUE ATTRIBUTES : 


oe 


000000 


000000 


000000 
032767 
000002 
DISK 
Q2 


~000000 


000000 — 
000000 
000040 
000000 


CORE 


— -Q3 


000000 
000000 
000000 
000040 
000000 


CORE 


Q4 

000000 
000000 
000000 
032767 
000000 


DISK 
Q5 
000000 
000000 
Q00000 


032767 
000000 


DISK 


Q6 
000000 
OOO000O0 
000000 
032767 
O00000 


DISK 


PURGE Q2, 


ALL ; 


QUEUE NAME : 
NUMBER OF DELETED MESSAGES ;: 


QSTATUS Q1 , Q2; 


PRINT Qi, 


PURGE Qi, 


PURGE Q3 , 


QUEUE NAME : 

NUMBER OF COMPLETE MESSAGES _ ; 

NUMBER OF MESSAGES IN SEND PHASE =: 
NUMBER OF MESSAGES IN RECEIVE PHASE : 
MAXIMUM NUMBER OF BLOCKS IN POOL 3 
NUMBER OF BLOCKS USED FROM POOL :; 
PROGRAM QUEUE 

QUEUE ATTRIBUTES :; 


QUEUE NAME : 

NUMBER OF COMPLETE MESSAGES) ; 

NUMBER OF MESSAGES IN SEND PHASE =: 
NUMBER OF MESSAGES IN RECEIVE PHASE ;: 
NUMBER OF BLOCKS ALLOCATED TO THIS QUEUE 
NUMBER OF BLOCKS USED FOR THIS QUEUE : 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : 


Q3 , Q5 , 2635 

QUEUE NAME ;: 

NUMBER OF COMPLETE MESSAGES 3; 
QUEUE NAME =: 
NUMBER OF COMPLETE MESSAGES 3; 
QUEUE NAME :3 

NUMBER OF COMPLETE MESSAGES — 3: 


QUEUE NAME ;: 
NUMBER OF COMPLETE MESSAGES 


ao 


NUMBMSG = 1 ; 


QUEUE NAME ; 
NUMBER OF DELETED MESSAGES 


ALL 3 


‘ QUEUE NAME : 


PURGE Q4, 


NUMBER OF DELETED MESSAGES 


NUMBMSG = 3 3 
QUEUE NAME 3 


-. “NUMBER OF DELETED MESSAGES: 


PRINT Q33 


QUEUE NAME :; 
NUMBER OF COMPLETE MESSAGES ; 


Ci) 


Q2 
000000 


Qi 

000000 
000000 
Q00000 
032767 
000002 


DISK 


Q2 
000000 
000000 
000000 
000040 
000000 


CORE 


Qi 
000000 
Q3 
000000 


Q5 
000000 


Q6 
000000 


Qi 
000000 


Q3 
0000 


Q4 
000000 


Q3 
000000 


APPENDIX C 


MAM AND QMAINT ERROR MESSAGES 


Error mesSages output after the execution of an MCS application appear in the 
JOR (job occurrence report). 


Error messages output after the execution of the QMAINT utility are, 
e those which are written to the SYSOUT file 
o those which appear in the JOR 


FORMAT OF ERROR MESSAGES 


The format of the SYSOUT error message is, 


ERROR QC nnnn SEVERITY (s) error-message-text | 


The format of the JOR error message is, 
QCnn error-mesSage-text | 


where, 
e QC denotes that the source 
- in the case of the SYSOUT error message is the QMAINT utility 
- in the case of the JOR error message can be either an MCS application or 
the QMAINT utility 
e nnnn and nn, respectively are the number of the message 
e S is the severity of the error condition as follows, 
- 2: warning 
- 3 3: fatal, leading to a. QMAINT abort but allows a complete syntax ana- 
lysis 
- 4 3 fatal, leading to a QMAINT abort and may prevent syntax analysis 
9 error-message-text gives the error condition and may be accompanied by the 
return code of the format 
RC = XXXXXXKX—-YVVVVVVY » ZZZZZZZzZ 
- XXXxXxxxx : hexadecimal contents of the RC register 
- yyyyyyyy : name of the SIU (system integration unit) procedure 
~ ZZ222z2zzz 2. return code | 


C-O1 


00 


‘MAM JOR 
-05 | 


“QCOO BMAM NOT AVAILABLE 


— Qco1 


Qco2 


QCOo3 


QCO04 


QCco5 


Syntax : as in text _ | 

cause : the step attempted has aborted because 
| « CNC utility has not yet been run to create the network 

« CNC utility is currently executing 

« the step itself is ea aaa and was not linked with the 
option LINKTYPE = BMAM > 

action : either generate the network or wait until the current CNC session 
| has terminated or link the step, before retrying the job 


MAXIMUM NUMBER enn eenes IS EXCEEDED 


Syntax : aS in text 
cause : the step attempted has aborted due to more than 26 QASSIGN state- 
ments in the step enclosure 


action : correct the JCL statements and retry the job 


ee eee UNKNOWN EXTERNAL QUEUE NAME 


syntax : as in text — 
cause : the step attempted has dpoveea because a QASSIGN Statement speci - 
a fies an BeeEGee as aaeedeenamer that has not yet been defined in the 
| network | 
action ; as the network using CNC utility and retry the agp 


external-queue-name QUEUE NOT AVATLABLE 


syntax : as in text 

cause : the step attempted has been aborted because a QASSIGN Statement 

| specifies an “external queue" currently allocated to another step 
action : retry the job later when the other step has terminated 


symbolic-queue-name DUPLICATE SYMBOLIC QUEUE NAME 


syntax : as in text | 

cause : the step attempted has sieeted because a QASSIGN statement speci- 
fies a "symbolic-queue-name" that, has already been assigned in 
another QASSIGN statement of the same step 

action : correct the JCL statements and retry the job 


external-queue-name DUE ETGSTE: EXTERNAL QUEUE NAME 


Syntax : as in text 

cause : the step attempted has aborted because a OQASSIGN statement. speci- 
fies an "'external-queue-name" that has already been assigned in 
another QSSIGN statement of the same step 

action : correct the JCL statements and retry the job 


G-02 


MAM JOR 
07-14 


QCO7 BMAM: ABORT USER RC= xxxxxxxx-eyyyyyyyy , 2222z2zz 


Syntax : the contents of RC specifies the system error 

cause : the step attempted has aborted due to an error condition at run- 
time 

action : see "Return Codes" 


QcO8 process-neme :; UNABLE TO START USER PROCESS 
syntax : applicable only to 2 multiprocess step 
cause : the step attempted has aborted because a user process identified 
by "process-name"' cannot be started 
action : check the report of the linking process for the load-module and 
correct the linking as necessary, and retry the job 


QCO9 UNABLE TO OPEN CIVF FILE RC= xxxxxxxx-eyyyyyyyy 5 ZZZZZZ222Z 


Syntax : the contents of RC specifies the error and system primitive 

cause : the system file containing the network description is unable to be 
opened due to a system error 

action : perform ISL with "clean restart", regenerate the network and rerun 
the job 7 


QCiO CNG SESSION IN PROGRESS 


syntax : as in text 

cause the CNC utility is currently executing 

action : wait until the current CNC session has terminated before retrying 
the j Obe 


ee eo 


QCi1l QUEUES FILE MEDIA BUSY/NOT AVAILABLE RC= xxxxxxxx--yyyyyyyy » 22222z2z 


syntax : as in text 

cause : the disk queue file is not avartaDre for processing or has not 
been mounted 

action : retry the job or mount the disk queue file and rerun the job 


QC12 MAXIMUM NUMBER OF MAM PROCESS GROUPS EXCEEDED 


syntax : as in text | | 

cause : the number of process groups has exceeded the number specified by 
the MAMNB parameter of the GENCOM command 

action : correct the GENCOM command, regenerate the network using CNC uti- | 
lity and retry the job 


QC14 external-queue-name’': INVALID KEYWORD REPLY IN QASSIGN 


syntax : as in text 

cause : a QASSIGN statement has a "reply" keyword which does not relate to 
a program queue 

action : correct the JCL statements and retry the job 


C-03 


MAM JOR 7 
17-26 


-gc17 keyword s SYNTAX ERROR. ‘INVALID KEYWORD IN CONTEXT 


- syntax> : "keyword" specifies the mismatch between the queue type, either in- 
| put or output, and the associated parameter in eee | 

cause 3: see syntax — 

action : correct the JCL Statements, ‘and retry the job. 


QC23 ‘eMetelt ~ queue- name ZERO LENGTH QUEUVE/SUBQUEUE NAME 


Syntax :as in text 
cause : the step has abereed because the "symbolic- queue-name" of $QASSIGN 
has been partitioned into "'subqueues" of the wrong format, for ex- 
ample, a missing '.'"' or 2 contiguous ". ''s, 
action : correct the format of the "symbolic-queue-name" of the $QASSICN, 
and retry the JOP: | 
QC24 symbolic- subqueue -name :; "SYMBOLIC SUB- QUEUE-1"' FIELD IS BEING FORCED TO 


1 SPACES 


syntax 
cause 


as in text | 
during a RECEIVE, only the igyabolte=queuslt represented by either 
"data-name-1'"' or QUEUE NAME is to contain the data. 

All other levels of "subqueues" starting with either "data-name-2" 
or SUBQUEUE_NAME corresponding to "SYMBOLIC SUB-QUEUE-1" are not 
used and must be set to spaces. 

action : correct either the program or the "symbolic-queue-name" in $QUSSIGN. 


QC25 sale ian : "SYMBOLIC SUB-QUEUE- 2"' FIELD IS BEING FORCED TO 
SPACES 


as in text 

during a RECEIVE, eaily the "SYMBOLIC QUEUE" and "SYMBOLIC suB- 
QUEUE-1"' represented by either "data-name-1" and eGabarnemere! or 
QUEUE_NAME and SUBQUEUE_NAME are to contain data. 

All other levels of "subqueves" starting with either ’agee~hatie oo 
or SUBQUEUE2_NAME corresponding to "SYMBOLIC SUB-QUEUE-2" are not 

| used and must be set to spaces. 

action : correct either the program or the "'symbolic-queue-name'"' in $QASSIGN. 


Syntax 
cause 


es ee 


Ae 


-name : "SYMBOLIC Pheer 3" FIELD IS BEING FORCED TO 


QC26 symbolic subqueue, 
| | ; SPACES 


as in text | 
during a RECEIVE, only the "SYMBOLIC QUEUE", "SYMBOLIC SUB-QUEUE-1" 
and "SYMBOLIC-SUB-QUEUE-2"' represented by either "data-name-1"', 
- “data-name-2" and "data-name-3" or QUEUE NAME, SUBQUEUE_NAME and 
SUBQUEUE2_NAME are to contain data. 
The ''subqueue'"' defined by either "data-name-4" or SUBQUEUE3 NAME 
corresponding to "SYMBOLIC SUB-QUEUE-3"' is not used and must be set 
to spaces. 
action ; correct either the program or the "symbol {.c-quaue-name" in $QASSIGN. 


Syntax 
cause 


ee es 


MAM JOR 
37 


QC37 QMON ABORTS AT ADDRESS address RC=return-code 


syntax 


cause 


action 


e 
@ 


e 
e 


“return-code"' is of the format RC = xxxxxxxx-- yyyyyyyy , 22Z2Zzz2Z 


where 


- xxxxxxxx : hexadecimal contents of the RC register 

- yyyyyyyy : name of the SIU (system integration unit) procedure 

- 2Z222zZzz : return-code | 
QMON has aborted because of a system error as indicated by the 
“return-code'" 

consult the list of general "return-codes" in the Error Messages 
and Return Codes Reference Manual, and if this message occurs fre- 
quently on the job report, call the field engineering service and 
transmit the return code(s), as applicable. 


Note : The network control operator is advised to issue "ST QMON" 
to reStart QMON in order to continue the execution of the 
MCS application(s). 
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: RETURN CODES 


AB- EX 


| ABTPRC | 


definition: 
definition: 
action H 
1 COUNTOV 
definition: 
action : 


definition: 
action : 
| CPOV 
definition: 
action : 
definition: 
action : 


an invalid internal condition, such as, invalid data or data out 
of range, has been detected during processing a disk I/O request 
resulting in discontinuation of file processing — 

take a dump and call the field engineering service 


BINS has been started for a network generated without LINE defi- 


nition 


insert the. el LINE command(s) and rerun CNC utility 


the threshold of 1/0 errors defined at initialization has been 

exceeded resulting in the non-execution of the pending I/O oper- 

ation and subsequent shut-down 

« either try to copy the file affected and retry the job 

e or, if the file fails to be copied, preallocate a new file, 
reinitialize the system, regenerate the network and retry the 
job 


a channel program error or hardware malfunction has occurred 
retry; if the same condition occurs, call the field engineering 
service 


an internal error while trying to start multiple channel pro- 
grams simultaneously has occurred 
call the field engineering service 


a request has been made to read or write a record outside the 
limits of the allocated file 

retry; if the same condition occurs, call the field engineering 
service 


wet 


definitions 
action g 
1 MSGOV | 


definition: 
action : 
| NEXPDERR | 


definition: 


action - 3 


definitions: 
action : 


RETURN CODES 
MD- TA 


the file was not in the "ready" state when accessed by an 1/0 
operation 

set the file in the "ready" state either using the same drive or 
a different drive, and retry the job with the option MAM=YES 


a disk 1/0 request specifying an invalid number of records, such 
as less than O or greater than 5, has been attempted 
take a dump and call the field engineering service 


either VCAM or MAM has been preloaded and locked in memory 
thereby preventing the execution of CNC utility 

use the CMM command to cancel the locked segment and rerun CNC 
utility 


an internal system error has occurred 
call the field engineering service 


C-07 


The rest of the QC messages apply for the QMAINT utility only. a 


C-08 


QCGO 


QC07 


QCO9 


Qc1i0 


QC11 


Qc15 


QMAINT JOR 
00-15 


BMAM NOT AVAILABLE 


syntax : 


cause 


action 


aS in text 
: QMAINT utility has aborted because 
» CNC utility has not yet been run to create the network 
« CNC utility is currently executing 
; either generate the network or wait until the current CNC session 
has terminated, before rerunning QMAINT utility 


BMAM : ABORT USER RC= xXxxxxxxx—-yyyyyyyy , ZZZZZZZz 


syntax 
cause 
action 


UNABLE 


syntax 
cause 


action 


UNABLE 


syntax 


cause 


action 


QUEUES 


syntax 
cause 


action 


UNABLE 


syntax 


cause 


action 


: the contents of RC specifies the system error 
: QMAINT utility has aborted due to an error ovceero8 at run-time 
: see "Return Codes" 


TO OPEN CTIVF FILE RC= 


: the contents of RC specifies the error and system primitive 

: the system file containing the network description is unable to be 
opened due to a System error 

perform ISL with "clean restart", regenerate the network and rerun 
QMAINT utility | 


XXXXXXXX—- YVVYVVVVY » ZZZZZZzzZ 


eo 


TO ACCESS CTVF FILE RC= xxxxxxxx-yyyyyyyy , ZZZZzZZZz 


: the contents of RC specifies the error and system primitive 

: the system file containing the network description cannot be ac- 
cessed due to a system error 

perform ISL with "clean restart", regenerate the network and rerun 
QMAINT utility 


FILE MEDIA BUSY/NOT AVAILABLE RC= xxxxxxxx-eyyyyyyyy » ZZZZZZZz 


as in text 

the disk queve file is not available for processing or has not 
been mounted 

s retry QMAINT utility later or mount the disk queue file and rerun 
QMAINT utility 


oe $60 


TO ACGESS SYSOUT RC= xxxxxxxx—-yyyyyyyy , 2Z22ZZZZzZ 


: the contents of RC specifies the reason for the abort and the sys- 
tem primitive 

QMAINT processing was aborted due to an error in accessing the 
SYSOUT file 

retry; if the same condition occurs, call the field eneineering 
service | 


30 


eo 


C-09 


QMAINT SYSOUT | 


—103 ~ 302 


_@ ERROR QC | 0103 | SEVERITY (4) ILLEGAL SYNTAX 


syntax: 
cause : 


action 3: 


t denotes the element in error. 7 
one or a combination of the following, 
« wrong command name, keyword or argument 
« violation of QMAINT reserved syntax 
correct the command(s) and rerun QMAINT utility 


e ERROR QC | 0110 | SEVERITY (4) END OF MESSAGE STRING MISSING 


-@ ERROR QC 0113 


@ ERROR QC ; 0201 


@ ERROR QC 0302 


Syntax 
cause 


action : 


as in text 
a message to be sent to a queue must be terminated 
in one of the following ways 
. either by the ENDMSG ortion in the SEND command 
- or by a card delimiter after the last message. 
text card specifying //EOM starting at column 1 
correct the message string bv either method and re- 


run QMAINT acl 


SEVERITY (3) MESSAGE SENT TOO LONG - 


syntax 
cause 


action 3: 


as in text 


an attempt has been made to send a message longer 


than the maximum acceptable to MAM, resulting in 


overflow; the maximum is 3053 bytes. 


truncate the message to be sent and rerun QMAINT u- 
tility 


SEVERITY (4) UNABLE TO ACCESS SYSIN 
RC= XXXXXXXX--YYYYYYVVY » ZZZZZ2Zz 


syntax $ 


cause 
action 


ee 6¢ 


the contents of RC specifies the reason for the a- 
bort | 

system error | 

check JCL statements and retry the job; if the same 
condition occurs, call the field engineering ser- 
vice | 


SEVERITY (2) INVALID NAME LENGTH : name 


syntax : 


cause : 


action 3: 


'name"' specifies the external queue used in the 
QMAINT command concerned 
the "external- -queue-name"' must obey the following 
rules, 
- limited to up to 12 alphanumeric characters 
- specified previously in an associated QUEUE 
command 


ate QMAINT command ‘and rerun QMAINT aie 
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QMAINT SYSOUT 
304 - 405 


® ERROR QC | SEVERITY (3) DUPLICATE KEYWORD 


Syntax : as in text 
- cause : a keyword has occurred more than one in a command 
action : correct the appropriate command and rerun QMAINT u- 
tility 


e ERROR QC SEVERITY (2) INVALID LENGTH PARAMETER 


Syntax : as in text 

cause 3; error in the syntax of the SEND command : the LENGTH 
value conflicts with the actual length of the mess- 
age bounded by the string specified in ENDMSG | 

action : correct the LENGTH value and rerun QMAINT utility 


@ ERROR QC 


SEVERITY (2) QUEUE UNKNOWN : name 
Syntax : "name'' specifies the external queue used in the 
QMAINT command concerned 
cause : the "external-queue-name" has not been defined in 
the network declared 
action : correct the "external-queue-name" in the appropri- 
ate QMAINT command and rerun QMAINT utility 
e ERROR QC | SEVERITY (2) QUEUE NOT AVAILABLE : name 
| syntax : '"name'' specifies the external queue used in the 
QMAINT command concerned | 
cause : the "external-queue-name" identifies either a pro- 
gram queue currently allocated to another applica- 
tion or having active connections, or a terminal- 
queue to which a terminal is still logged 
action : wait until the queve identified becomes available 
and rerun QMAINT utility | 
@ ERROR QC | SEVERITY (4) FAILED TO CREATE SEGMENT : segment-name 


RG = XXXXXXXX-"YYYYVYVVY » ZZZZZZZZ 


syntax : "segment-name''! specifies the internal name of a 
work segment that QMAINT utility was unable to cre- 
ates the contents of RC specifies the reason for 
the abort | 

system error 

retry; if the same condition occurs, call the field 
engineering service 


cause 
action 


86 90 


QMAINT SYSOUT | 


409 - dal 


e ERROR QC {| 0412 


"SEVERITY @ ABNORMAL RECEIVE FROM QUEUE : mame _ 
RC = XXXXXXXX—-yyyyyyyy 5 2ZZZZzzZzZ me 


syntax 


cause 


action 


"name" specifies the external queue to which a 


_ RECEIVE was issued; the contents of a SEecennGe 


the reason for the abort 

MCS error | | 

retry; if the same condition occurs, call ene field 
engineering service 


SEVERITY (3) ABNORMAL SEND TO QUEUE : name 
RC = XXXXXXXX--YYYYVYYVVY » ZZZzZzZzzZzz 


syntax 


cause 


action 


"name"! specifies the external queue to which a SEND 
was issued; the contents of RC specifies the reason 
for the abort 

MCS error | 

retry; if the same condition occurs, call the as 
engineering service 
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APPENDIX D 


COMMUNICATIONS STATUS KEY CONDITIONS 


The CD entries specify the interface area DEMeenice and the application, and 
define the parameters required, as follows, 


» between MCS and the application, 


- ACCEPT (H_MSGCNT) : which ascertains the number of messages in a sym- 
bolic queue identified by the name of the input 
CD area of the application 


- RECEIVE (H_RECEIVE) : which requests a message from a specified symbo- | 
lic queve identified by the name of the input CD 
area of the application 


- SEND (H_SEND) ' $3 which directs a message to a specified symbolic 
queue identified by the name of the output CD a- 
rea of the application 


e between MCS and the terminals, 


- DISABLE (H_DISABLE) : which terminates the logical connection with spe- 
cified sources or destinations for data transfers 
to and/or from the terminals 


- ENABLE (H_ENABLE) : which establishes the logical connection with 
specified sources or destinations for data trans- 
fers to and/or from the terminals. 


The CD entries are defined as follows, 
-. in MCS COBOL, in the Communication Section 


'o« in GPL, by the system primitive H_CD. 


The status of this MCS interface is given by a set of status key codes, each u- 
niquely defined by 2 alphanumeric characters denoting the status of each of the 


parameters, that is, the "x'' in the appropriate column of the table denotes the 
parameter specified. 


The parameters listed are in alphabetical order and include all the functions of 
DISABLE (H_DISABLE) and ENABLE (H_ENABLE). 


The status key codes from 9A through 9E are only applicable if the appropriate 

program-queue on which the application will receive control messages concerning 

events and the change in terminal status, has been defined with the BREAK option 
in the QUEUE command at network generation. | 


: COMMUNICATIONS | STATUS 


‘Communications Status Key Conditions: 


ACCEPT ($H MSGCNT) 


($H_ )DISABLE INPUT TERMINAL a ‘* unknown means that symbolic 
|($H_)DISABLE INPUT queue is not defined in JCL 
($H )DISABLE OUTPUT 


($H_)ENABLE INPUT TERMINAL 
($H )ENABLE INPUT 
($H )ENABLE OUTPUT 


B ($H_) RECEIVE 
$H_)SEND _ 


no error detected, re completed 


1 or more destinations eisap nes action completed 


1 or more queues/ subqueues unknown *, no action taken 


Labels and locations 
are specified in COBOL 


-~ 


no action ve for 1 or more destinations Ganon *, 
action taken for known destinations, 

data- name-4, ERROR KEY, indicates known or unknown * 
DESTINATION COUNT invalid, no action taken 


password invalid, no enable/disable action taken 


Giasdcres cere en of sending field, no ac- 
tion taken 


partial segment with O character count or no 
sending area specified, no action taken 


message data not transferred to quéue due to un- 
availability of mass storage 


ve) 
jms 


| Yo) Ne) Ye) om | et w ~~ 
|e felelele|s|{sisfs} 3 [ele 


message data not transferred dua. to unavai Labi 1i- 
ty of memory space 


N 


no data can be input from the terminal to the 
queue to which a ($H_)DISABLE has been issued 


uo 


all message data not transferred because maximum 
mesSage size exceeded, message truncated 


message too long, truncated to maximum size epee 
cified 


Oo 


ES A A A OO OH 
oe ee 
a AT Sa A RN ARNON! A PS SO 0 


message discarded due to queue allocation overflow 


source unknown *, no action taken y 


COMMUNICATIONS STATUS 


Communications Status Key Conditions 


(continued) 


: : t , : ‘ : aes : 


s ACCEPT ($H MSCCNT) 


B($H )DISABLE INPUT TERMINAL _ * unknown means that symbolic 
($H )DISABLE INPUT | | queue is not defined in JCL 
($H ) DISABLE OUTPUT 


Labels and locations 


i ($H_)ENABLE INPUT TERMINAL | are specified in COBOL 
| |($H_ )ENABLE INPUT _ 
($H_ )ENABLE OUTPUT 


ee ) RECEIVE 
S($H )SEND 


message data returned but at least 1 previous 
smeseaee has been rose 


pdcnee cies 2 in H _)SEND # NOM, mg, nen or ae 


m message deka not ay due to ‘to error on 
s disk file | 


access to queve in conflict with JCL definition 


eel Cy es (ee 
[ane (i I eT ER 


BREAK has been detected, queue corresponding to 
symbolic source has been disabled 


RVI has been detected, queue corresponding to 
ieymorse source has been acdcen 


terminal ee ee to seateiter source has 

been disconnected 

ceeninal weevessondine: to 5 eeabelee source has 
: pees comneer ee 


Shueacuy is apnceuces: ppplecacien is required 
to terminate 


access to queue in conflict with JCL definition, 
or related terminal not logged on to application 


if mesSage not transferred, checkpoint should be ta- 
3 ken before attempting further data transfers, 
s applicable to queues with CTLRST option 


|; 
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